| << Retour à l'affichage précédent |
|
[EXP-3207] BI : accès à BI lorsque le site est en maintenance Création: 31/janv./07 10:08 Mise à jour: 25/juin/07 19:00 Résolue: 13/mars/07 17:31 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Agathe Remy | Attribution: | Jérémie Bennejean |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Description |
|
Bonjour, Lorsque le site est en maintenance, l'application BI est aussi passée en maintenance. Ce n'est pas normal : pouvez-vous y remédier? Merci:-) Agathe |
| Commentaires |
| Commentaire de Antoine Koener [ 31/janv./07 15:45 ] |
|
Le site est reUP |
| Commentaire de Antoine Koener [ 31/janv./07 16:07 ] |
|
Il faut séparer les services pour les internautes des services pour l'interne. Je vais donc sortir bi.priceminister.com du reste des serveurs et le rendre actif à tout moment, tant en mode production qu'en mode maintenance. Peut être que d'autres services pourront être déplacés de la même façon ? |
| Commentaire de Antoine Koener [ 07/mars/07 14:36 ] |
|
Il faudrait maquetter la chose suivante: -extraire la configuration du vhost bi.priceminister.com de la configuration globale de apache, pour en faire un vhost normal - desyncrhoniser le mode maintenance de ce vhost avec les autres. Afin de réaliser la desynchronisation il faut simplement que dans le repertoire maintenance ce trouvent des fichiers de configuration identiques à ceux de production pour le vhost bi. La bascule entre prod et maintenance ne doit pas avoir d'effet sur le vhost bi. Il faut donc que le jk, les rewrite et autres soient les memes entre prod et maintenance pour bi. A dispo pour en discuter. |
| Commentaire de Jérémie Bennejean [ 12/mars/07 12:32 ] |
| Ok, je fais le test en pre prod, ensuite sur la prod. |
| Commentaire de Justin Ziegler [ 13/mars/07 09:48 ] |
|
pour info, QV est deja comme cela. meme si le site est en maintenance, on a toujours acces a QV |
| Commentaire de Jérémie Bennejean [ 13/mars/07 17:29 ] |
|
vu avec Antoine, Le vh bi ne pointe jamais sur le repertoire maintenance mais tjrs sur production. Quelque soit le mode, les rewrites rules et jk interrogés sont tjrs ceux de production. Conclusion: le script pmapachemaintenance n'impactera jamais bi.priceminister.com |
| Commentaire de Justin Ziegler [ 13/mars/07 17:54 ] |
|
heu ? c pas clair la ! tu es en train de dire qu'il n'y a pas de pb ? ou tu es en train de dire que tu as resolu le pb en faisant une modif ? |
| Commentaire de Jérémie Bennejean [ 13/mars/07 18:15 ] |
|
Une modification a été faite afin de résoudre le pb. La voici: Include conf/production/rewrite.rules Include conf/production/mod_jk.redirect.bi Quelque soit le mode, le virtualhost bi est toujours accessible. Nous avons testé avec un autre vh en pre prod. |
[EXP-2514] BI : procédure de redémarrage des serveurs BI en PROD Création: 07/août/06 15:42 Mise à jour: 16/avr./08 13:47 |
|
| Etat: | Ouvert |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Agathe Remy | Attribution: | Sébastien Raguet |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Bonjour, Serait-il possible d'inclure le redémarrage des applis BI dans les procédures de redémarrage en Production : - les instances OWREP, BOREP et DW sur latone - les services BusinessObjects sur tellus cf doc de JEB pour la DEV. Merci:-) Agathe |
| Commentaires |
| Commentaire de Antoine Koener [ 09/mai/07 17:53 ] |
|
Voici une bonne suggestion :p Peut être travailles-tu déjà sur cela ? |
| Commentaire de Agathe Remy [ 15/avr./08 14:52 ] |
|
Bonjour Patrice, Sais-tu si cela a finalement été fait? Ou bien attend-on la migration sur le serveur dédié? Merci:-) Agathe |
| Commentaire de Patrice Boulanger [ 15/avr./08 15:02 ] |
|
En fait, étant donné qu'on a des alertes sur les process BO
sur Tellus et à terme sur le serveur BI dédié, ça devient moins urgent.
En cas de plantage de la machine, même si on oublie de relancer les
services BO, on recevra des alarmes. Ceci dit, il est toujours prévu de mettre en place des procédures dédiées par serveur donc ce sera le cas pour le serveur BI. |
| Commentaire de Patrice Boulanger [ 16/avr./08 13:47 ] |
|
Sébastien, à inclure dans les procédures en cas de crash de serveurs. Merci. |
Migration du mécanisme d'import des fichiers de Phaeton vers Bacchus
(EXP-2759)
|
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Evolution |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Sous-tâche | Priorité: | Critique |
| Rapporteur: | Patrice Boulanger | Attribution: | Eric Vannier |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Description |
|
Le B.I. utilise Phaeton à plusieurs niveaux: 1. transfert de fichiers vers la plateforme de prod en scp: -> aujourd'hui, les fichiers sont copiés dans /tmp/agathe sur phaeton -> prévoir un répertoire spécifique pour le B.I. 2. latone, titan et junon copient et cryptent des fichiers sur phaeton pour les envoyer en FTP (et peut-être HTTP cf. François) vers les partenaires. -> vérifier l'installation de gpg sur bacchus -> copier les clés de cryptage de phaeton sur bacchus -> migrer les scripts du B.I. vers bacchus -> migrer la copie depuis latone, titan et junon vers bacchus et valider le transfert vers les partenaires. |
| Commentaires |
| Commentaire de Eric Vannier [ 02/oct./06 14:53 ] |
|
1°) J'ai crée un répertoire "bi" dans /tmp de Phaeton pour que celui-ci soit utilisé pour le transfert vers la prod. Le B.I. est en charge de faire sa purge régulière. 2°) gpg est installé sur Bacchus, j'ai réalisé la copie des clés de cryptage de Phaeton sur Bacchus |
| Commentaire de Patrice Boulanger [ 02/oct./06 15:02 ] |
| J'ai mis Agathe en observatrice du JIRA pour avoir son avis sur la question et sa validation |
| Commentaire de Eric Vannier [ 17/nov./06 11:21 ] |
| La migration s'est bien passée du côté du BI. |
| Commentaire de Patrice Boulanger [ 02/janv./07 10:46 ] |
| Donc je résous |
[BIN-520] [Tracking] : étude comparative DI / BI Création: 17/nov./08 17:01 Mise à jour: 17/déc./08 15:39 Résolue: 18/nov./08 18:24 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Mathieu Richomme | Attribution: | Dalila Belkebir |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Export_DI20081107-bis.xls
Export_DI20081107_01.xls
Export_DI20081107_02.xls
extraction panier tracking pour MKT le 18 11 2008.xlsx
|
||||||||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Description |
|
Bonjour Agathe, en PJ un export avec les données DI 1 purchase id par ligne, pour chaque ligne nous souhaiterions compléter avec les données BI: - last tracking 30 jours BI - volume d'affaire BI - commission BI d'avance merci! Mathieu |
| Commentaires |
| Commentaire de Dalila Belkebir [ 17/nov./08 18:27 ] |
|
OK alors il y a 2 fichiers comportant chacun environ 20 000 paniers. Donc : => on est loin des 5 x 2000 paniers à extraire prévu initialement dans le JIRA http://pricejira/browse/BIN-505 => lequel des fichiers dois-je prendre en compte ? Merci. Dalila. |
| Commentaire de Mathieu Richomme [ 17/nov./08 18:53 ] |
|
Export_DI20081107-bis.xls 5 onglets de 2000 lignes merci |
| Commentaire de Dalila Belkebir [ 18/nov./08 12:41 ] |
|
Mathieu, J'ai généré 4 000 extractions à partir des 2 000 ALL et 2 000 LS hors marque. J'ai pour cela utilisé les mêmes infos que celles indiquées dans le rapport Purchase tracking by month (cf JIRA 505). Le fichier est disponible sur le serveur ALL et dans le répertoire : T:\BI\01 - Demandes ponctuelles\demandes GGR tracking extract pr etude avec DI\extraction du 17 11 2008 Peux-tu STP me valider que ce sont les bonnes infos que vous attendez ? Auquel cas je continue les autres extractions. Sinon, donne moi plus de précisions. Merci. Je passe te voir pour aller plus vite. Cordialement, Dalila. |
| Commentaire de Dalila Belkebir [ 18/nov./08 18:24 ] |
|
Mathieu, C'est fait. Tu trouveras le résultat dans le répertoire BI du serveur All ou attaché au JIRA. Cordialement, Dalila. |
| Commentaire de Mathieu Richomme [ 19/nov./08 10:59 ] |
|
parfait Merci Dalila! |
[EXP-3566] BI : impossibilité d'arrêter la plateforme de Production?!!! Création: 09/mai/07 18:35 Mise à jour: 25/juin/07 19:01 Résolue: 22/juin/07 14:48 |
|
| Etat: | Fermé |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Agathe Remy | Attribution: | Jérémie Bennejean |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Il semblerait que nous n'ayons pas le droit d'arrêter nos services BusinessObjects sur tellus parce que cela génère des alertes auprès de l'équipe d'exploitation et de notre hébergeur?!!! Nous aimerions bloqué l'accès à notre application aux utilisateurs. Arrêter notre application nous semblait une bonne solution, mais bon... Dépité, nous nous disons que, dans ce cas, l'URL d'accès bi pourrait être redirigé vers une page de maintenance, mais ce n'est pas possible non plus?! Que pouvons nous donc faire pour interdire l'accès à notre application aux utilisateurs lors des phases de maintenance? Merci:-) Agathe |
| Commentaires |
| Commentaire de Antoine Koener [ 10/mai/07 16:40 ] |
|
Agathe, on va regarder cela de plus près, en attendant, la phase de maintenance dure combien de temps ? Quel est le risque réél ? Ma question nous permettra de déterminer la solution la plus appropriée, afin de rapidement mettre quelquechose en place :) |
| Commentaire de Agathe Remy [ 10/mai/07 17:02 ] |
|
La maintenance est à présent terminée. Pour la petite histoire, nous avons fait une mise en production la semaine dernière et, en raison du plantage du SAN vendredi, nous n'avons pas pu finir de la tester:-( Notre alimentation a donc planté dans la nuit de vendredi à samedi:-((( Hier, nous avions donc 4 jours d'alimentation à rattraper. Nous avons donc voulu couper l'accès à notre application BI afin d'empêcher nos utilisateurs de faire des requêtes sur notre Datawarehouse alors que nous étions en train de le mettre à jour. L'objectif était à la fois d'éviter qu'ils se retrouvent avec des données incohérentes et de faire en sorte que leurs actions ne pénalise pas le rattrapage en surchageant la base pour rien. Les risques réels sont donc : - pour l'utilisateur, d'avoir des données incohérentes ou simplement fausses - pour nous, d'avoir des problèmes de temps de chargement dus aux requêtes des utilisateurs Est-ce que cela répond à ta question? Agathe |
| Commentaire de Antoine Koener [ 11/mai/07 10:18 ] |
|
Absolument. Est-ce que déjà tu aurais une idée de comment faire simplement ? Est-ce que de bloquer l'accès au site te semble suffisant ? Est-ce que vous voulez être indépendants sur ces mises en maintenance ou bien aller vous passer par un interlocuteur de notre équipe ? |
| Commentaire de Antoine Koener [ 11/mai/07 15:28 ] |
|
Il faut décider de la méthode à mettre en place, ensuite savoir si JET serait ok ne mettre un nouveau script exécutable par sudo... Qu'en penses-tu ? |
| Commentaire de Patrice Boulanger [ 11/mai/07 16:58 ] |
|
Je suggére de ne pas passer par Jet. Actuellement, il y a une rewrite.rules qui redirige: RewriteCond %{HTTP_HOST} ^bi.* RewriteRule ^/$ http://bi.priceminister.com/businessobjects/enterprise115/ [L,R] On en ajoute une qui sera commentée, et qui redirige vers un maintenance.asis. On fera l'opération manuellement comme ça on sera prévenu du début et de la fin de la maintenance. |
| Commentaire de Antoine Koener [ 14/mai/07 11:21 ] |
|
Jérémie peux-tu s'il te plait t'occuper d'ajouter un
commentaire dans les fichiers de rewrite nous permettant de rapidement
trouver la règle à commenter pour mettre le BI en maintenance ? Une fois cela fait pourrais-tu mettre à jour ton wiki pour refléter cette modification ? Merci |
| Commentaire de Jérémie Bennejean [ 15/mai/07 14:43 ] |
|
Voila ce que j'ai ajouté à la fin du fichier du rr.V900 #REGLE POUR MAINTENANCE BI UNIQUEMENT #RewriteCond %{HTTP_HOST} ^bi.* #RewriteRule ^/$ http://bi.priceminister.com/bi.maintenance.asis [L,R] Pour mettre le bi en maintenance il faudra commenter la règle existante: RewriteCond %{HTTP_HOST} ^bi.* RewriteRule ^/$ http://bi.priceminister.com/businessobjects/enterprise115/ [L,R] Et décommenter la nouvelle. Cela vous convient? |
| Commentaire de Jérémie Bennejean [ 15/mai/07 14:45 ] |
| Il s'agit du rr.V900 se trouvant ds le rep production. |
| Commentaire de Patrice Boulanger [ 16/mai/07 15:54 ] |
|
Comme vu avec Jérémie, cette solution ne marche pas car le
JkMount du VH bi redirige toutes les servlet vers le tomcat sur tellus.
On peut donc changer la redirection en: #REGLE POUR MAINTENANCE BI UNIQUEMENT #RewriteCond %{HTTP_HOST} ^bi.* #RewriteRule ^/$ http://www.priceminister.com/bi.maintenance.asis [L,R] Et créer une page spécifique pour ce site. Merci. |
| Commentaire de Jérémie Bennejean [ 16/mai/07 16:09 ] |
| C'est fait, quand pouvons-nous faire un test ? |
| Commentaire de Jérémie Bennejean [ 28/mai/07 11:19 ] |
| Vu avec Agathe pour le 18 juin. |
| Commentaire de Jérémie Bennejean [ 22/juin/07 14:48 ] |
|
La regle de redirection est en place. Nous l'activerons à la demande d'Agathe. |
Finalisation installation de BO en PROD
(EXP-772)
|
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | Sébastien Tournay | Attribution: | Ranto Andriambololona |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Rediriger l'URL http://bi.priceminister.com vers http://bi.priceminister.com/businessobjects/enterprise11/desktoplaunch/InfoView/logon/logon.do pour arriver directement sur l'applicatif BI et éviter de prendre les pages par défaut TOMCAT/APACHE
|
| Commentaires |
| Commentaire de Ranto Andriambololona [ 05/janv./06 15:08 ] |
|
C'est fait ... Pour tester il faut cliquer sur http://bi.priceminister.com/ |
[EXP-3189] BI Espagne : besoin de créer le user BABEL_BI sur la base Espagne Création: 25/janv./07 11:18 Mise à jour: 25/juin/07 19:00 Résolue: 01/févr./07 12:19 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Nouvelle fonctionnalité | Priorité: | Bloquant |
| Rapporteur: | Agathe Remy | Attribution: | Patrick Pereira |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Serait-il possible de mettre en place le user BABEL_BI avec les synonymes privés sur toutes les tables en Espagne en Integ et en Prod? Merci:-) Agathe |
| Commentaires |
| Commentaire de Antoine Koener [ 25/janv./07 17:13 ] |
| Est-ce possible ? |
| Commentaire de Patrick Pereira [ 26/janv./07 14:02 ] |
| Fait en integ. |
| Commentaire de Patrick Pereira [ 26/janv./07 14:06 ] |
| En plus droits pour le user BABEL_BI pour exécuter les fonctions Toeuro() et toeuro2() |
| Commentaire de Patrick Pereira [ 01/févr./07 12:19 ] |
| Fait en prod. |
[BIN-469] [BI Import] : Mise en place reporting / BI Data_file Création: 24/juil./08 16:30 Mise à jour: 13/nov./08 19:09 Résolue: 13/nov./08 19:09 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Justin Ziegler | Attribution: | Dalila Belkebir |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
STATISTIQUES IMPORT.rar
|
| Pays: |
FRA - France
|
| Description |
|
L'intégrale en un seul épisode : Il s'agit d'un projet qui se veut "Quick win techno driven" pour l'équipe commerciale, par le biais de l'équipe param / import. L'idée est de ne prendre que la table data_file dans l'alim. Celle-ci contient déjà plusieurs dénormalisation / stat issus de la table data_line. Il faudra aussi prendre les tables de code voisines : type de fichier, status... Il faut prendre cette table de façon incrémentale. Les rapports intéressants au niveau fichier : 1/ Evolution du nb de partenaire utilisant le système d'import. Soit le nb de partenaire distinct présent dans la table data_file par mois, par jour. On souhaite suivre la croissance de cette info. Un graphe serait sympa. 2/ Evolution du nb de fichiers arrivés dans le système d'import, par type de fichier et tous types de fichier confondus. Soit le nb de ligne présent dans la table data_file par mois, par jour. On souhaite suivre la croissance de cette info. Un graphe serait sympa. 3/ Le focus sur un partenaire précis doit être possible : évolution nb de fichier & nb de ligne sur une période. 4/ Hit parade (top 100 par ex) des plus gros utilisateurs du système d'import (sur les n derniers jour ?) : en nb de ligne (par mois / par jour) et en nb de fichier. 5/ Le meme que le précédent mais en ordre inverse. Objectif : détecter ceux qui faisaient des imports réguliers et qui soudainement n'en font plus. Les rapports intéressants au niveau ligne : 1/ Evolution dans le temps (jour / mois) du nombre de lignes traitées, taux de réussite, par type de fichier / type de traitement. Temps de traitement moyen d'une ligne si possible. 2/ Evolution dans le temps (jour / mois) du nb d'annonce (de produit) crée / mis à jour / supprimé 3/ top 20 identifiant les partenaires dont le temps de traitement moyen de la ligne est le plus long. Début d'idées pour les statistiques souhaitées pour Frédéric : - Avoir des statistiques de délais (délais de traitement, délais d'attente, durée de vie d'un import) - Définir des statistiques sur le type de traitement utilisé (création annonces, mise à jour produits, etc..) - Lister tous les login n'utilisant pas les imports depuis X temps - Lister les profils ou les format non utilisés [[ ATTENTION : rester sur data_file dans un premier temps]] - Faire un rapprochement entre le taux de succès des imports et le chiffre d'affaire du partenaire (afin de pouvoir prioriser l'optimisation des Imports) [[ ATTENTION : rester sur data_file dans un premier temps]] Dans un deuxième temps : - rapprochement avec d'autres info : ventes, annulation |
| Commentaires |
| Commentaire de Dalila Belkebir [ 24/juil./08 17:26 ] |
|
L'épisode 2 : Scénariste Frédéric Acteurs : Frédéric et Dalila. Voici un petit résumé sur la présentation des Imports à Dalila: - Présentation du métiers Import - Présentation des outils Imports (BO, format, profil, fichiers, FTP) - Présentation des statiques réalisées par rapport à nos outils (TABLE DATA_FILE) (voir fichier ci-joint) : 1/ Statistiques sur les partenaires utilisant les Imports (Comparatif par rapport aux années précédentes) 2/ Statistiques sur les fichiers soumis (Comparatif par rapport aux années précédentes) 3/ Statistiques sur le nombre de lignes traitées (Comparatif par rapport aux années précédentes) 4/ Statistiques sur le taux de réussite des imports (Comparatif par rapport aux années précédentes) Statistiques sur l'evolutions des courbes 1,2,3,4 (depuis 2005 à nos jours) L'idéale serait de bénéficier de ses stats automatiquement et dynamiquement, comme par exemple avoir la les courbes Import pour un login en particulier, etc ... => Début d'idées pour les statistiques souhaitées pour ma part : - Avoir des statistiques de délais (délais de traitement, délais d'attente, durée de vie d'un import) - Définir des statistiques sur le type de traitement utilisé (création annonces, mise à jour produits, etc..) - Lister tous les login n'utilisant pas les imports depuis X temps - Lister les profils ou les format non utilisés - Faire un rapprochement entre le taux de succès des imports et le chiffre d'affaire du partenaire (afin de pouvoir prioriser l'optimisation des Imports) Etc.... Cordialement Frédéric NAHUM Responsable Pôle Import Tel : 01.42.78.79.80 |
| Commentaire de Dalila Belkebir [ 24/juil./08 17:29 ] |
| Statistiques d'import de Frédéric NAHUM |
| Commentaire de Dalila Belkebir [ 13/nov./08 19:09 ] |
|
Bonjour, Le projet est livré en production. Un lot 2 est déjà planifié sur 2009 pour prendre en compte des évolutions "qualitatives" suite à l'analyse des données mises à disposition. Merci à tous de votre participation, et tout particulièrement à l'équipe BI. Cordialement, Dalila. |
[BIN-103] problème BI Création: 07/juin/06 15:39 Mise à jour: 14/sept./07 17:02 Résolue: 07/juin/06 16:53 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Bug & Improvement |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Elodie Pasquale | Attribution: | Samir Beghdadi |
| Résolution: | Corrigé | ||
| Estimation restante: | 2 heures | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | 2 heures | ||
| Description |
|
BI ne marche toujours pas pour recall/new buyers after mailing jai une fenêtre d'erreur qui s'ouvre WIS 00005 Error INF Elodie elodie.pasquale@priceminister.com Tel : +33 (0)1 42 78 87 15 |
| Commentaires |
| Commentaire de Samir Beghdadi [ 07/juin/06 16:53 ] |
| C'est bon le problème est réglé après avoir modifié le chemin de l'objet Purchase display month pour le filtre Select authorization month period. |
[INF-64] Demande d'accès aux emails et aux interfaces de supervision BI depuis chez moi Création: 22/mai/08 17:03 Mise à jour: 05/nov./08 16:46 Résolue: 05/nov./08 16:46 |
|
| Etat: | Résolu |
| Projet: | Infrastructure |
| Composants: | Micro |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Agathe Remy | Attribution: | Ange Ferrari |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Bonjour, L'idée est que je puisse vérifier le bon fonctionnement des alimentations BI (et éventuellement les relancer) depuis chez moi. Pour cela, la solution semble de remplacer mon PC par un portable pas trop lourd parce que je suis petite, mais pas trop cher, avec un station de travail et un sac à dos? Il me faut au moins 1Go de RAM sous Windows XP pour pouvoir exécuter les outils BI et 40 Go d'espace disque pour les installer. Les accès nécessaires sont : - accès à la messagerie - accès aux serveurs de Production en ssh (latone, tellus) - accès à bi.priceminister.com - accès à Oracle Entreprise Manager : http://latone.lan:5500/em/, http://latone.lan:5501/em/, http://latone.lan:5502/em/ et éventuellement : https://supervision.priceminister.jmh:11000/ Pour info, je dispose chez moi d'une connexion free. J'espère que je n'ai rien oublié et reste à votre disposition pour répondre aux questions. Merci. Agathe |
| Commentaires |
| Commentaire de Justin Ziegler [ 22/mai/08 17:12 ] |
| Pourrait on en profiter pour migrer Agathe en imap ? |
| Commentaire de Agathe Remy [ 09/juin/08 11:10 ] |
|
Bonjour, J'ai terminé l'installation des outils BI sur le portable. Tout semble bien fonctionner:-) Etape suivante : l'accès à distance... Merci. Agathe |
| Commentaire de Stéphane Eccli [ 09/juin/08 11:29 ] |
| repasse moi le ticket apres ouverture du VPN |
| Commentaire de Agathe Remy [ 10/juin/08 10:06 ] |
|
Voici mon IP fixe : 81.56.56.49 Agathe |
| Commentaire de Ange Ferrari [ 12/juin/08 09:46 ] |
|
Pour l'accès à la supervision https://supervision.priceminister.com:11000/ avec ton login et mdp habituel pour le reste je te tiens au courant au fur et à mesure de l'avancée des choses |
| Commentaire de Ange Ferrari [ 12/juin/08 11:40 ] |
|
pour bi.priceminister.com c'est en place |
| Commentaire de Ange Ferrari [ 20/juin/08 14:01 ] |
|
JET a procédé à l'ouverture du flux ssh peux tu valider le fonctionnement ? |
| Commentaire de Agathe Remy [ 08/juil./08 09:55 ] |
|
ça marche trop bien!!! A part en wifi où ça coupe tout le temps... Mais avec un cable réseau, j'ai réussi depuis chez moi à me connecter : - aux serveurs de Production en ssh (latone, tellus) via phaeton.priceminister.com - à bi.priceminister.com en créant un tunnel sur tellus - à Oracle Entreprise Manager : http://latone.lan:5500/em/, http://latone.lan:5501/em/, http://latone.lan:5502/em/ en créant un tunnel sur latone J'ai oublié de vérifier l'accès à la supervision : https://supervision.priceminister.jmh:11000/ ?! Ne me manque plus que l'accès à la messagerie! Merci et j'attends vos nouvelles pour le dernier point. Agathe |
| Commentaire de Agathe Remy [ 02/oct./08 10:37 ] |
|
Bonjour, Je n'arrive plus à accéder à BusinessObjects en Production (bi.priceminister.com). Peut-être est-ce lié à la migration du serveur BO sur elasippos. S'il vous plait, pouvez-vous regarder ce qu'il en est? Merci. Agathe |
| Commentaire de Agathe Remy [ 05/nov./08 16:44 ] |
|
Bonjour, Suite aux modifs de la semaine dernière, j'ai testé mes accès BI ce week-end (02/11/2008) et cela fonctionne parfaitement. Merci! Vous pouvez clôturer le JIRA. Agathe |
[EXP-1928] Plus d'accès à http://bi.pm.lan Création: 03/mai/06 15:35 Mise à jour: 25/juin/07 18:57 Résolue: 04/mai/06 11:20 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Troubleshooting |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Bloquant |
| Rapporteur: | Agathe Remy | Attribution: | Jérémie Bennejean |
| Résolution: | Corrigé | ||
| Estimation restante: | 0 minutes | ||
| Temps consacré: | 5 minutes | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Tout à coup, nous n'avons plus d'accès à l'url suivante: http://bi.pm.lan Pour info, il est 15h35 le 03/05/2006... |
| Commentaires |
| Commentaire de Sébastien Tournay [ 04/mai/06 10:40 ] |
| En tout cas ce matin cela marche ... Jérémie vous avez fait quelque chose ? Agathe, vous étiez en train de redémarrer votre application ? |
| Commentaire de Jérémie Bennejean [ 04/mai/06 11:20 ] |
|
Quand le site est passé en maintenance, tout la conf apache pointe sur un rep maintenance. Dans ce répertoire il y a un ficher de rewrite rules, qui indique à apache que les pages vers bi ne sont pas redirigées vers la page de maintenance. Or avant hier bi n'étais pas redirigé vers la page de maintenance, d'ou l'affichage d'une page "erreur page non trouvée" |
[BIN-608] [FINANCE] écart entre les chiffres de VA Titan et BI Création: 08/juil./09 17:06 Mise à jour: 17/août/09 15:33 Résolue: 09/juil./09 15:30 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Finance |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Matthieu Azema | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
200906 - Ecarts GMS capturé.xls
|
||||||||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Description |
|
Dans le rapport BI Financial/Confidential/ "Purchase summary
by month", le montant qui ressort pour le mois de juin en "Captured
gross merchandized sold" est de 8930648.73. Dans le rapport Titan "Commission breakdown", la somme des colonnes "Val Art" + "Total FPA" + "Total Garanties TTC" (avec un filtre sur la période de juin 2009) est censé nous donné le même montant que celui issu du BI (cf ci-dessus). Hors pour juin, il ressort un montant de 8931680.21 soit un écart de 1031.48 Merci Matthieu |
| Commentaires |
| Commentaire de Agathe Remy [ 09/juil./09 15:30 ] |
|
Bonjour Mathieu, Je viens de vérifier : les chiffres sont identiques entre terra et BI (normalement de GMS du rapport BI "Purchase summary by month" est comparé aux montants du rapport terra "paniers_coupons_articles". L'écart provient d'une différence que nous ne savons pas expliquer entre le montant réellement capturé (débité l'acheteur) et celui qui aurait du l'être. Nous avons ainsi identifié 52 paniers autorisés entre les 16 et 18/06 (capturés entre les 18 et 24/06) constituant cet écart de 1031.48¿. Il s'agit donc d'un incident sur le site. Si tu as besoin d'en savoir plus, je t'invite donc à ouvrir un bug auprès des équipes Développement. Agathe |
| Commentaire de Agathe Remy [ 09/juil./09 15:55 ] |
|
Vous trouverez ci-joint les 52 paniers qui expliquent cet écart : - l'un est une erreur de capture manuelle - les 51 autres restent inexpliqués Agathe |
| Commentaire de Christophe Garcia [ 09/juil./09 16:35 ] |
|
Ca sent la modif de frais de port (shipping size 1540) .... 2009-06-18 19:23:22,990 INFO [10.150.28.77] CAPTURE - Purchase Id : 72503236 2009-06-18 19:23:23,007 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Recommandé R1 mode for the shipping size 1540 2009-06-18 19:23:23,013 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Recommandé R1 mode for the shipping size 1540 -- 2009-06-18 20:07:32,971 INFO [10.150.28.77] CAPTURE - Purchase Id : 72471229 2009-06-18 20:07:32,985 INFO [10.150.28.77] REQUEST - Processed: 35 (REQUESTED: 35) 2009-06-18 20:07:32,990 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540 2009-06-18 20:07:32,994 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540 -- 2009-06-18 20:09:49,155 INFO [10.150.28.77] CAPTURE - Purchase Id : 72489036 2009-06-18 20:09:49,173 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Recommandé R1 mode for the shipping size 1540 2009-06-18 20:09:49,178 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Recommandé R1 mode for the shipping size 1540 -- 2009-06-18 20:59:39,058 INFO [10.150.28.77] CAPTURE - Purchase Id : 72470161 2009-06-18 20:59:39,080 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540 2009-06-18 20:59:39,089 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540 -- 2009-06-18 22:42:12,047 INFO [10.150.28.77] CAPTURE - Purchase Id : 72484708 2009-06-18 22:42:12,063 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540 2009-06-18 22:42:12,068 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540 -- 2009-06-18 22:44:18,067 INFO [10.150.28.77] CAPTURE - Purchase Id : 72498824 2009-06-18 22:44:18,089 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Recommandé R2 mode for the shipping size 1540 2009-06-18 22:44:18,109 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Recommandé R2 mode for the shipping size 1540 -- 2009-06-18 23:28:29,117 INFO [10.150.28.77] CAPTURE - Purchase Id : 72428578 2009-06-18 23:28:29,132 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540 2009-06-18 23:28:29,137 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540 2009-06-18 23:28:29,153 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540 2009-06-18 23:28:29,156 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540 -- 2009-06-18 23:28:33,928 INFO [10.150.28.77] CAPTURE - Purchase Id : 72440146 2009-06-18 23:28:33,950 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540 2009-06-18 23:28:33,955 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540 -- 2009-06-18 23:28:44,431 INFO [10.150.28.77] CAPTURE - Purchase Id : 72445974 2009-06-18 23:28:44,452 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540 2009-06-18 23:28:44,457 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540 2009-06-18 23:28:44,479 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540 2009-06-18 23:28:44,483 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540 -- 2009-06-18 23:28:50,778 INFO [10.150.28.77] CAPTURE - Purchase Id : 72448855 2009-06-18 23:28:50,796 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540 2009-06-18 23:28:50,801 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540 |
[APP-26299] [Migration CBV] Créer une vue pour éviter des impacts au BI Création: 27/août/09 14:57 Mise à jour: 21/sept./09 11:14 Résolue: 28/août/09 10:36 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 53.0.0 (TX-I) |
| Version(s) corrigée(s): | 53.0.0 (TX-I) |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Arnaud Forgues | Attribution: | Arnaud Forgues |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Projets PM archivés: | Extensions de garanties (Lot 1) : Articles neufs | ||||||||
| Description |
|
Lors de la migration CBV permettant de synchroniser le
système de configuration du CBV avec celui des EG, on a modifié la
notion de type de garantie de la manière suivante : - type CBV_INTERNAL (20) ==> type CBV (40) + flag is_external_managed = 0 - type CBV_EXTERNAL (10) ==> type CBV (40) + flag is_external_managed = 1 Cette modification ayant des impacts non négligeable en terme de timing pour l'équipe BI, l'idée est de créer une vue pour maintenir l'ancienne modélisation. On modifiera alors le synonyme "babel_bi.warranty" en le faisant pointer vers la nouvelle vue ! |
| Commentaires |
| Commentaire de Arnaud Forgues [ 28/août/09 10:36 ] |
|
Une nouvelle vue "warranty" vient donc remplacer l'ancien
synonym "warranty" qui pointait vers "purchase_1.warranty". Le script
est à passer en POST DEPLOY le jour même du déploiement Il se trouve ici : V:\Database\TX-I\integ\TX-I_MIGRATION_CBV_14_FR_create_view_for_bi.sql |
[INF-462] [BI] : Arrivée de 2 stagiaires BI le 10/05/2010 Création: 23/avr./10 16:32 Mise à jour: 10/mai/10 14:29 Résolue: 10/mai/10 14:29 |
|
| Etat: | Résolu |
| Projet: | Infrastructure |
| Composants: | Arrivée/Départ |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | Christophe Garcia |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
FICHE NOUVEL ARRIVANT FLL.doc
FICHE NOUVEL ARRIVANT MFB.doc
|
| Description |
|
Bonjour, 2 stagiaire de fin d'étude BI arrive le 10/05/2010 pour 6 mois : Fabrice LIMA LOPES (FLL) et Meriam Fatima BOUAICHA (MFB) Toutes les infos sont dans les fiches nouvel arrivant ci-jointes. A ta dispo si tu as besoin d'autres infos. Merci, Agathe |
| Commentaires |
| Commentaire de Agathe Remy [ 06/mai/10 11:53 ] |
|
Bonjour Stéphane, Stp, est-ce que tu pourras également ajouter leurs emails à l'alias biteam@priceminister.com? Merci, Agathe |
| Commentaire de Stéphane Eccli [ 07/mai/10 16:23 ] |
| comptes créés reste jira |
| Commentaire de Christophe Garcia [ 10/mai/10 12:32 ] |
|
J'ai besoin de leurs 2 adresses mails. Merci |
| Commentaire de Stéphane Eccli [ 10/mai/10 12:35 ] |
|
fabrice.lima-lopes@priceminister.com meriam-fatima.bouaicha@priceminister.com |
[EXP-4635] [ BI UK ] Création des instances BDD pour BI UK Création: 04/déc./08 15:48 Mise à jour: 17/déc./08 11:15 Résolue: 17/déc./08 11:05 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Evolution |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Nouvelle fonctionnalité | Priorité: | Bloquant |
| Rapporteur: | Dalila Belkebir | Attribution: | Patrick Pereira |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
GBR - Royaume Uni
|
| Description |
|
Bonjour Patrick, Dans le but de démarrer les devs du projet BI UK nous avons besoin que tu nous créées : 1 - Création sur la base DW DEV : Pommery Schéma // Tablespace ODS_UK /// ODS_UK et ODS_UK_IX DWH_UK /// DWH_UK et DWH_UK_IX DTM_UK /// DTM_UK et DTM_UK_IX RT_UK /// RT_UK et RT_UK_IX 2 - Création sur la base DW PRD : Latone Schéma // Tablespace ODS_UK /// ODS_UK et ODS_UK_IX DWH_UK /// DWH_UK et DWH_UK_IX DTM_UK /// DTM_UK et DTM_UK_IX RT_UK /// RT_UK et RT_UK_IX Donc pour chaque environnement : 4 schémas : ODS_UK DWH_UK DTM_UK RT_UK Avec 2 tablespaces par schéma, l'un portant le même nom que le schéma (pour les tables), l'autre avec l'extension _IX pour les indexes. Il nous faut ces environnements pour : DEV : dès que possible afin de démarrer les devs (les spécifications étant quasi finies). PROD : 02/01/2009 N'hésite pas à nous contacter si tu as besoin de plus d'informations. Merci de ton retour. Dalila. |
| Commentaires |
| Commentaire de Patrick Pereira [ 09/déc./08 11:11 ] |
|
Les tablespaces et users ont été créés en dev (password = login). Je transmets la demande à Didier B. pour la prod. |
| Commentaire de Patrick Pereira [ 09/déc./08 11:24 ] |
| Ticket 6438 créé chez Jet |
| Commentaire de Agathe Remy [ 09/déc./08 11:31 ] |
|
Trop cool:-) Merci! |
| Commentaire de Patrick Pereira [ 17/déc./08 11:05 ] |
| C'est fait en prod aussi. |
| Commentaire de Dalila Belkebir [ 17/déc./08 11:15 ] |
|
OK, merci Patrick. On vérifie et on te fait un retour. dalila. |
[BIN-177] BI Espagne : lot 1 Création: 13/oct./06 17:15 Mise à jour: 14/sept./07 17:22 Résolue: 13/août/07 18:41 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Sales |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Nouvelle fonctionnalité | Priorité: | Bloquant |
| Rapporteur: | Agathe Remy | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Σ Estimation restante: | Non spécifié | Estimation restante: | Non spécifié |
| Σ Temps consacré: | Non spécifié | Temps consacré: | Non spécifié |
| Σ Estimation originale: | Non spécifié | Estimation originale: | Non spécifié |
| Liens des demandes: |
|
||||||||
| Sous-tâches: | |||||||||
| Pays: |
ESP - Espagne
|
||||||||
| Description |
|
Mise en place du lot 1 BI Espagne
|
[INF-192] BI bloqué sur ma machine Création: 03/nov./08 10:26 Mise à jour: 04/nov./08 11:20 Résolue: 04/nov./08 11:20 |
|
| Etat: | Résolu |
| Projet: | Infrastructure |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Mathieu Richomme | Attribution: | Stéphane Eccli |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Bonjour Stéphane, vu avec Agathe ce matin il faudrait désinstaller un composant Java pour que mes rapports BI puissent tourner d'avance merci pour ton aide, Mathieu |
| Commentaires |
| Commentaire de Stéphane Eccli [ 04/nov./08 11:20 ] |
| ok |
[INF-293] BI : Arrivée de Geoffroy le 06/04/2009 Création: 25/mars/09 18:12 Mise à jour: 04/mai/09 16:25 Résolue: 04/mai/09 16:25 |
|
| Etat: | Résolu |
| Projet: | Infrastructure |
| Composants: | Arrivée/Départ |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | Christophe Garcia |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
FICHE NOUVEL ARRIVANT GVI.doc
|
| Description |
|
Bonjour, Un stagiaire de fin d'étude BI arrive le 06/04/2009 pour 6 mois : Geoffroy VIGNERON (VGI) Il prendra le poste de Florian AMBROSI qui termine son stage le 31/03/2009. Toutes les autres infos sont dans la fiche nouvel arrivant ci-jointe. A ta dispo si tu as besoin d'autres infos. D'autre part, suite au changement de poste de Dalila, serait-il possible de réattribuer son ancien poste (ou équivalent) à Cyril pour remplacer son vieux Transtec et son écran qui s'éteint sans raison? Dans le package Office, il faut qu'il ait PowerPoint notamment pour les formations BI. Merci. Agathe |
| Commentaires |
| Commentaire de Agathe Remy [ 25/mars/09 18:13 ] |
|
Voici la fiche de nouvel arrivant! Agathe |
| Commentaire de Agathe Remy [ 30/mars/09 18:33 ] |
|
J'en profite également pour te demander de supprimer florian.ambrosi@priceminister.com de l'alias biteam@priceminister.com et de le remplacer par l'email de Geoffroy:-) Merci! Agathe |
| Commentaire de Stéphane Eccli [ 03/avr./09 11:51 ] |
| comptes ok, reste Jira |
[BIN-700] Export BI Pros / Seo Création: 09/déc./10 11:25 Mise à jour: 22/déc./10 14:10 Résolue: 20/déc./10 12:18 |
|
| Etat: | Résolu |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Thierry Leforestier | Attribution: | Valéria Gusa |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Dans le cadre d'une étude, nous avons besoin d'un export du BI contenant les colonnes suivantes :
SELLER_LOGIN || PRODUCT_ID || CA AUTHORISED || CA CAPTURED Pour les critères suivants : Vendeurs pros uniquement Produits vendus avec et sans stock, produits non vendus avec stock (oui.. c'est un peu tordu) Période de vente : 30 jours précédant l'export (ou mois précédent) N'hésitez pas si il y a besoin de plus de précisions. |
| Commentaires |
| Commentaire de Valéria Gusa [ 20/déc./10 12:16 ] |
|
Les données ont été extraites dans le fichier suivant : /data/priceminister/pmshare/tle/
Valeria. |
| Commentaire de Valéria Gusa [ 20/déc./10 12:17 ] |
|
Pardon, j'ai oublié le nom du fichier : ExtractBI_SEO.csv
Valeria |
| Commentaire de Thierry Leforestier [ 22/déc./10 14:10 ] |
|
Merci c'est top, on va pouvoir analyser ça tranquillement, je vous tiens au courant.
Thierry |
[BIN-624] [FINANCE] : Ecart GMS capturé juillet 2009 entre Titan et BI Création: 12/août/09 12:13 Mise à jour: 30/sept./09 17:23 Résolue: 07/sept./09 12:28 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Finance |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Matthieu Azema | Attribution: | Julien Girardet |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
aout_cancelled_items_bug_warranties.xls
cancelled_items_bug_warranties.xls
|
||||||||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Description |
|
Dans le rapport BI Financial/Confidential/ "Purchase summary
by month", le montant qui ressort pour le mois de juin en "Captured
gross merchandized sold" est de 8852276.47 > Dans le rapport Titan "Commission breakdown", la somme des colonnes > "Val Art" + "Total FPA" + "Total Garanties TTC" +"Total EG TTC" (avec un filtre sur la > période de juillet 2009) est censé nous donné le même montant que celui > issu du BI (cf ci-dessus). Hors pour juillet, il ressort un montant de > 8856292.93 soit un écart de 4016.46 Merci Matthieu |
| Commentaires |
| Commentaire de Agathe Remy [ 17/août/09 11:33 ] |
|
Bonjour Matthieu, Comme la dernière fois, l'écart ne se situe pas entre BI et Titan, mais entre les décompositions article et panier : tu peux constater le même écart en comparant les rapports BI "Purchase summary by month" et "Commission breakdown by month". En effet, il est du à un bug dév lors de la MEP des EG : des garanties ont été capturées sur des paniers annulés (cf JIRA Agathe |
| Commentaire de Matthieu Azema [ 17/août/09 11:44 ] |
|
Bonjour Agathe, Effectivement, cet écart a bien été identifié. Malheureusement, ce n'est pas le seul. Après investigations, il semblerait que le rapport Titan comptabilise 2 fois la capture de la valeur article et des frais de port associés et ce, uniquement lorsque l'acheteur a souscrit à la fois à la garantie CBV et à L'EG. Matthieu |
| Commentaire de Julien Girardet [ 07/sept./09 12:28 ] |
|
Bonjour Matthieu, Les rapports Terra sont corrigés. Pour les rapports BI, c'est en cours de correction. Julien. |
| Commentaire de Julien Girardet [ 14/sept./09 12:14 ] |
|
Bonjour Mathieu, Une fois le rapport TERRA "Commission breakdown" corrigé (livré la semaine derniere), il existe encore un écart avec le rapport BI "Purchase summary by month" En effet pour le mois de Juillet : Rapport "Commission breakdown" TERRA : la somme des colonnes "Val Art" + "Total FPA" + "Total Garanties TTC" +"Total EG TTC" = 8848169,02 Rapport "Purchase summary by month" : Captured gross merchandized sold : 8852276,47 Donc il existe un écart de 4107.45 Cet écart provient des montants garanties capturés à tord sur des articles annulés au mois de Juillet (voir bug cbv) Voici le listing des articles concernés par cet écart. La somme des montants garanties (CBV+ EG) de ces articles correspond à l'écart : 4107.45 A ta disposition pour plus d'informations. Julien. |
| Commentaire de Julien Girardet [ 14/sept./09 18:37 ] |
|
Mail de Philippe : Bonjour Julien, Merci pour les modifications apportées aux rapports Titan "panier coupon article" et "commission breakdown". Pour le mois de juillet ne subsiste donc plus effectivement que l'écart de 4 107,45 euros que tu mentionnes ci-dessous (et qui est expliqué). Sur août on a également un petit écart de 1,23 euros entre : - le VA ressortant du commission breakdown de Titan et ; - le VA du "panier coupon article" de Titan / le VA du "purchase summary by month" de BO. Matthieu va investiguer pour essayer de comprendre ce dont il s'agit ; si besoin on te sollicitera. Merci Philippe -------------------------------- Reponse : Bonjour Philippe, Cet ecart provient également du bug CBV, j'ai executé la meme requete pour lister les articles "victimes" de ce bug sur le mois d'Aout, et je trouve 2 articles ! Et bien sur la somme des garanties correpond à l'ecart : 1,23 Je ne pensais pas que le bug était encore present sur le mois d'aout... Ci joint le listing des articles concernés sur le mois d'aout. Julien |
| Commentaire de Dalila Belkebir [ 30/sept./09 13:45 ] |
|
Bonjour Philippe, Pourrais-tu STP nous valider ce JIRA pour clôture ? Merci d'avance, cdlt, Dalila. |
| Commentaire de philippe favrot [ 30/sept./09 17:19 ] |
|
Dalila, je te confirme que tu peux clôturer ce Jira. Merci à Julien pour tout ce travail de réconciliation Philippe |
[BIN-298] [Transverse] : Migration du Dashboard vers le BI Création: 28/févr./07 10:02 Mise à jour: 17/sept./10 17:58 |
|
| Etat: | Ouvert |
| Projet: | Business Intelligence |
| Composants: | Executive |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Quentin de Chivré | Attribution: | Julien Girardet |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
screenshot-1.jpg
|
| Pays: |
ALL - Tous
|
| Description |
|
Le tableau de bord en BO devra être supprimé le jour ou tous
les blocs (1 2 3 et 4, voir copie d'ecran) seront gérés par le BI. Avantages : - eviter de laisser acces a tout le monde a une info stratégique - c'est d'autant plus genant avec la croissance des effectifs de PM - eviter une double maintenance - compteurs pas synchros entre les 2 outils qui engendrent des question de la part de Philippe / bugs qu'on laisse trainer coté BO applicatif / etc... - eviter des calculs de données en Prod (tables ***_summary et batchs associés) qui sont consommateurs de ressources - simplifier / rendre cohérente l'architecture de plateforme Hier Agathe m'a montré un rapport qui (a priori) rend obsolete le bloc 4. Agathe, y a t'il des rapports correspondant aux autres zones ? Quand tu pensera que l'on a un rapport pour chaque zone, je suggère que tu fasse faire un sondage rapide auprès des différents décideurs pour confirmer la suppression du dashboard et des courbes associées. A ce moment, déplacer ce Jira côté Dev pour suppression du Dashboard. Que met t'on alors en HP du BO ? Bonne question, a voir avec Steven ? :-) |
| Commentaires |
| Commentaire de Justin Ziegler [ 28/févr./07 10:22 ] |
| attention, le rapport actuel d'Agathe ne traite que des 2 premieres colonnes de la zone 4 ! |
| Commentaire de Agathe Remy [ 02/janv./08 11:30 ] |
|
Romain, Voici un sujet de réflexion si un jour tu as du temps?! Agathe |
[EXP-1953] BI : Backup Perignon Création: 04/mai/06 17:36 Mise à jour: 25/juin/07 18:57 Résolue: 18/mai/06 17:04 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Maintenance |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | Jérémie Bennejean |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
admin.pdf
deploying_webintelligence_applications.pdf
Install_unix_win_fr.pdf
|
| Description |
|
Bonjour, Suite au mail de Jérémie, et après en avoir discuté avec Justin, il s'avère que la sauvegarde des développements BusinessObjects sur Pérignon ne consiste pas en une simple copie de répertoire. En effet, les développements sont stockés via un système de gestion de fichiers qui les versionne et les crypte. Il faut donc faire une étude sur la meilleure façon de les sauvegarder : faut-il utiliser un utilitaire BusinessObjects? La simple copie des répertoires suffit-elle pour restorer l'application? Faut-il aussi sauvegarder un clé de cryptage? Et que sais-je encore... Il s'agit d'une étude d'exploitation de l'outil BusinessObjects et il me semble que c'est à l'équipe Support de la mener. Je vous joins donc la documentation d'administration de BusinessObjects XI, mais je pense qu'elle est insuffisante et qu'une investigation auprès de l'éditeur sera nécessaire. Je reste à votre disposition pour toute question. Cordialement, Agathe |
| Commentaires |
| Commentaire de Sébastien Tournay [ 04/mai/06 17:43 ] |
| Pour l'instant l'équipe support c'est PAtrick et Edouard. On va donc demander à Edoaurd de creuser et valider ces aspects. |
| Commentaire de Justin Ziegler [ 04/mai/06 18:04 ] |
| Support ou pas, n'est ce pas un sujet pour Jeremy ? |
| Commentaire de Sébastien Tournay [ 04/mai/06 18:10 ] |
|
Non. Si nous sommes sur une phase d'étude il me semble
d'après ce que nous validons sur l'organisation que cela doit passer par
l'équipe Support. Pour moi c'est un sujet pour Edouard. En plus on est
sur des problématiques BDD+BI qui sont mieux maîtrisées par EDOUARD. Ne refaisons pas ce que nous avons déjà fait en sous estimant le chantier sauvegarde. |
| Commentaire de Agathe Remy [ 11/mai/06 12:05 ] |
|
Petite question : je pensais que l'équipe Support était
celle qui s'occupait de l'expoitation des plateformes internes et de
Production et que l'équipe Delivery était celle des études. Aurais-je
mal compris? Sinon, sur la sauvegarde des applis BI en interne : - Les bases de données BI sont toutes situées sur Pommery et leur sauvegarde a déjà été mise en place par Edouard et Pap. Elle a été dernièrement validée par Jérémie. - Il reste à mettre en place la sauvegarde des développements BusinessObjects situé sur Perignon. Après un parcours rapide des documentations jointes à ce JIRA et devant le manque de temps d'investiguer plus avant, je propose dans un premier temps de sauvegarder journalièrement l'intégralité de l'applicatif BusinessObjects, à savoir le répertoire /home/bo (3,3 Go) sur Perignon et tout ce qu'il contient. Après discussion aves Jérémie cette solution semble acceptable et rapide à mettre en place. Mais il est clair qu'elle n'est pas forcément la meilleure. Sébastien, serais-tu d'accord dans ce cas de réattribuer ce JIRA à Jérémie afin que l'on cloture ce sujet avant le retour d'Edouard? Merci:-) |
| Commentaire de Sébastien Tournay [ 11/mai/06 12:49 ] |
|
oupss.. C'est effectivement le rôle des 2 équipes. J'ai du aller un peu vite. Jérémie je te laisse terminer ce sujet. On pourrait l'inclure dans la boucle de sauvegarde de ce week-end. |
| Commentaire de Jérémie Bennejean [ 12/mai/06 18:10 ] |
|
J'ai ajouter dans le scritp de sauvegarde le répertoire que désire Aghate "/home/bo" ( 3.3Go) Une full quotidienne du repértoire sera ainsi faites. |
| Commentaire de Jérémie Bennejean [ 16/mai/06 10:55 ] |
| Mise en place sur LTO02 |
[EXP-2886] BI Espagne : environnement de développement Création: 24/oct./06 14:09 Mise à jour: 25/juin/07 18:59 Résolue: 27/oct./06 11:28 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | Jérémie Bennejean |
| Résolution: | Corrigé | ||
| Σ Estimation restante: | Non spécifié | Estimation restante: | Non spécifié |
| Σ Temps consacré: | Non spécifié | Temps consacré: | Non spécifié |
| Σ Estimation originale: | Non spécifié | Estimation originale: | Non spécifié |
| Sous-tâches: |
|
||||||||||
| Pays: |
ESP - Espagne
|
| Description |
|
Bonjour, Nous aimerions avoir une autre adresse IP avec un serveur name perignon_es sur perignon afin d'installer une deuxième instance de BusinessObjects. Merci:-) Agathe |
| Commentaires |
| Commentaire de Agathe Remy [ 25/oct./06 17:58 ] |
|
C'est juste bloquant pour mon équipe pour avancer sur la mise en place du BI Espagne... J'en profite donc pour étoffer la demande en ajoutant la mise en place d'une URL bi.es.dev Merci:-) Agathe |
| Commentaire de Jérémie Bennejean [ 26/oct./06 16:21 ] |
| cette @ est-elle temporaire comme dit au début ou souhaitez-vous la conserver ? |
| Commentaire de Jérémie Bennejean [ 26/oct./06 17:36 ] |
|
Nous aimerions avoir une autre adresse IP avec un serveur
name perignon_es sur perignon afin d'installer une deuxième instance de
BusinessObjects. --> C'est fait 192.168.1.14 perignon_es |
[EXP-3018] BI : Migration BusinessObjects sur Tellus Création: 22/nov./06 14:48 Mise à jour: 16/avr./08 13:44 Résolue: 16/avr./08 13:44 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Agathe Remy | Attribution: | Patrice Boulanger |
| Résolution: | Corrigé | ||
| Σ Estimation restante: | Non spécifié | Estimation restante: | Non spécifié |
| Σ Temps consacré: | Non spécifié | Temps consacré: | Non spécifié |
| Σ Estimation originale: | Non spécifié | Estimation originale: | Non spécifié |
| Sous-tâches: |
|
||||||||||||||||||||
| Pays: |
FRA - France
|
| Description |
|
Patrice, Il faut prévoir une migration de tellus vers RedHat AS 4, puis de BusinessObjects Release 1 vers la Release 2. Avant la migration, les étapes suivantes sont à prévoir : - sauvgarde de BOREP (~2.5 Go) sur Latone - création d'un nouveau schéma référentiel base de données sur l'instance BOREP de Latone - sauvegarde des répertoires /home/bo/bobje/data/frsinput (~180Mo) et frsoutput (~49Mo) Finalement, le plus tôt serait le mieux. Merci:-) Agathe |
| Commentaires |
| Commentaire de Patrice Boulanger [ 04/déc./06 11:13 ] |
| Avant de migrer Tellus, on va installer la nouvelle version sur Saturne qui est déjà en AS 4. Le compte "bo" a été créé sur ce serveur. L'accès firewall est en cours d'ouverture. |
| Commentaire de Patrice Boulanger [ 14/déc./06 10:08 ] |
|
La nouvelle version a été installé sur Saturne et est en cours d'utilisation par le B.I. On va programmer la mise à jour en Redhat AS4 update 4 sur Tellus dès que possible. |
| Commentaire de Patrice Boulanger [ 30/mars/07 16:55 ] |
|
La migration sur Tellus est terminée. |
| Commentaire de Justin Ziegler [ 06/août/07 15:15 ] |
| On peut fermer ? |
| Commentaire de Agathe Remy [ 06/août/07 15:24 ] |
|
Pas sure : Patrice voulait migrer BusinessObjects en interne de salon vers brice, je crois?! C'est une sous-tâche de ce JIRA non effectuée... Agathe |
| Commentaire de Patrice Boulanger [ 16/avr./08 13:44 ] |
| Migration BO sur serveur dédié prévue courant Q2 2008 |
[cobrand] SFR Metatache
(APP-14627)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Cobrandings |
| Affecte la/les version(s): | 12.0.0 |
| Version(s) corrigée(s): | 17.1.1 |
| Type: | Sous-tâche | Priorité: | Critique |
| Rapporteur: | Ghislain Gridel | Attribution: | Romain Czornomaz |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Site: | Prod |
| Projets PM: | *** RESERVE *** |
| Projets PM archivés: | Maintenance 12.0.0 |
| Commentaires |
| Commentaire de Ghislain Gridel [ 25/janv./07 10:36 ] |
|
Il faudra envoyer un rapport de type CAMIFau partenaire. Destinataire : julien.brault@fr.sfr.com Cependant, les délais de ce partenariat sont un peu particulier : Déploiement du cob : 06/02 Ouverture du portail SFR : début Avril Donc l'envoi du rapport se fera début avril. Merci Ghislain |
| Commentaire de Patrick Condevaux [ 25/janv./07 10:57 ] |
|
Desole, je ne peux pas deplacer cette sous-taches vers le projet BI (elle est deja liée a une tache APP) Agathe est-ce que tu veux que je cree un JIRA dans le projet BI ou ca te vas comme ca ? |
| Commentaire de Agathe Remy [ 25/janv./07 11:00 ] |
|
Le rapport existant déjà, c'est bon comme ça. Agathe |
| Commentaire de Thomas Séglard [ 02/avr./07 17:30 ] |
| Demande de rapport reportée à début mai. |
| Commentaire de Ghislain Gridel [ 10/avr./07 15:28 ] |
|
lancement du partenriat décalé au 25 mai. Ghislain |
| Commentaire de Agathe Remy [ 11/juin/07 18:40 ] |
|
Bonjour, Pourrais-je savoir où ça en est? Merci:-) Agathe |
| Commentaire de Ghislain Gridel [ 14/juin/07 17:02 ] |
|
C'est en ligne le 25 juin (normalement). tu peux donc programmer les rapports type "Camif" pour le dimanche 1er juillet. les contacts sont julien.brault@fr.sfr.com et cyril.clerget@fr.sfr.com merci. Ghislain |
| Commentaire de Ghislain Gridel [ 04/juil./07 11:53 ] |
|
Agathe, La mise en ligne est décalée au 9 juillet. Le rapport peut donc partir le 15 juillet. Merci. Ghislain |
| Commentaire de Agathe Remy [ 20/juil./07 19:20 ] |
|
Le reporting hebdo (2 rapports) est programmé à partir du
22/07/2007 et le reporting mensuel (listing des nouveaux comptes) à
partir du 02/08/2007. Cordialement, Agathe |
| Commentaire de Ghislain Gridel [ 20/juil./07 19:27 ] |
| ok. parfait merci. |
[BIN-273] [Finance] : Adaptation fonctionnelle de la gestion de la TVA pour les rapports BI pour les PLF rance et Espagne Création: 22/déc./06 12:18 Mise à jour: 25/juin/07 18:53 Echéance: 29/janv./07 00:00 Résolue: 11/mai/07 11:44 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Executive |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Critique |
| Rapporteur: | Fréderic Tiberghien | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Σ Estimation restante: | Non spécifié | Estimation restante: | Non spécifié |
| Σ Temps consacré: | Non spécifié | Temps consacré: | Non spécifié |
| Σ Estimation originale: | Non spécifié | Estimation originale: | Non spécifié |
| Pièces jointes: |
SF_BI_v2.doc
VAT_exempted_items_FR.csv
VAT_exempted_items_FR_200703.csv
VAT_items_ES.csv
VAT_items_ES_200703.csv
|
||||||||||
| Sous-tâches: |
|
||||||||||
| Pays: |
ALL - Tous
|
| Description |
|
Les specs BI pour l'Espagne précise un petit peu plus le besoin : P 32 - 34 (doc attaché) La modification fonctionnelle de la gestion de la TVA implique la création de 2 tableaux différents sur les plates formes France et l'Espagne. Cette refonte consiste à adapter précisément l'application de la TVA sur les commissions à la législation européenne. Sont donc introduits : la TVA espagnole et la notion d'exemption de la TVA. Les tableaux de bord BO à produire sont donc : ¿ Sur la plate forme française : TVA française 19,60% base x TVA calculée y TVA système z 5,50% base x TVA calculée y TVA système z 2,10% base x TVA calculée y TVA système z Total base somme des x = A TVA calculée somme des y = B TVA système somme des z = C Exo TVA base A Total général base Somme des A TVA calculée Somme des B TVA système Somme des C ¿ Sur la plate forme espagnole : TVA française 19,60% base x TVA calculée y TVA système z 5,50% base x TVA calculée y TVA système z 2,10% base x TVA calculée y TVA système z Total base somme des x = A TVA calculée somme des y = B TVA système somme des z = C TVA espagnole 16,00% base x' TVA calculée y' TVA système z' 4,00% base x' TVA calculée y' TVA système z' 2,10% base x' TVA calculée y' TVA système z' Total base somme des x' = A' TVA calculée somme des y' = B' TVA système somme des z' = C' Exo TVA base A'' Total général base A + A' + A'' TVA calculée B+ B' TVA système C + C' |
| Commentaires |
| Commentaire de Agathe Remy [ 22/déc./06 14:28 ] |
|
Frédéric, L'ancien rapport commission breakdown a été migré sous BusinessObjects depuis plusieurs mois. Je pense qu'il faudrait que tu vois à quoi ressemble le rapport actuel afin de baser tes spécifications sur des informations à jour. Peut-on se voir rapidement afin que je te présente le rapport actuel? Merci:-) Agathe |
| Commentaire de Fréderic Tiberghien [ 22/déc./06 14:36 ] |
|
je ne suis pas la la semaine prochaine, et je pars à 16h cet aprem. On se voit donx à la rentrée quand tu veux. La description des nouveaux tableaux à créer a été faite avec Philippe sur la base du nouveau tableau sorti sous BO dans l'onglet TVA, normalement reprise dans le doc joint page 32, si je ne me suis pas trompé. Et dans ce cas, ces tableaux doivent être modifiés. Fred |
| Commentaire de Agathe Remy [ 20/févr./07 19:06 ] |
|
Le nouveau rapport Commission breakdown by month a été livré en Production sur les plateformes France et Espagne. Les anciens rapports ont été conservés et renommés en Commission breakdown by month - old pour comparaison. Philippe, il ne te reste plus qu'à valider!!! Merci:-) Agathe |
| Commentaire de Philippe Favrot [ 27/févr./07 12:48 ] |
|
Agathe, merci pour la livraison de ce rapport. J'ai deux demandes de modifications de forme : - onglet "commission breakdown" : classer les mois dans l'ordre chronologique croissant (idem ancien rapport). - onglet "VAT breakdown" / Spain : au niveau du VAT country Spain rajouter des colonnes (qui seront à 0) dans le cas où la requête inclus des mois antérieurs à février de manière à avoir sur la même colonne toutes les informations (France / Espagne et Total) concernant un même mois. Par ailleurs pour pouvoir valider le fonds (c'est à dire la correcte ventilation des transactions par taux de TVA) peux tu me donner le détail des ventes (avec mention du vendeur : nom / pays et le type d'article) qui constituent les rubriques suivantes - "exonération" pour le rapport France (à ce matin il y avait par exemple 6 758 ¿ pour le mois de février) ; - 5,5 % / 19,6 % / 4 % / 16% du rapport Espagne . Merci Philippe |
| Commentaire de Agathe Remy [ 01/mars/07 19:29 ] |
|
Philippe, Pour l'extraction du détail des ventes, peux-tu me confirmer le format demandé: item_id;seller_account_id;seller last name;seller country; product type code ? D'autre part, lorsque tu parles de pays du vendeur, fais-tu allusion : - au pays de la transaction (VAT_COUNTRY) - au pays de paiement du vendeur - au pays d'expédition du vendeur (un vendeur peut se faire payer en France et expédier de Belgique) ??? Merci:-) Agathe |
| Commentaire de Agathe Remy [ 06/mars/07 21:37 ] |
|
Voici le listing des transactions effectuées sur la plateforme Espagne. Cordialement, Agathe |
| Commentaire de Agathe Remy [ 06/mars/07 21:40 ] |
|
Et voici le listing des transactions capturées exemptées de TVA sur la plateforme France. Je t'ai mis le détail des pays de paiement, de compensation et d'expédition parce que je me suis dit que ce serait le meilleur moyen pour toi de vérifier. Voici les règles de gestion qui étaient fournies dans les sépcifications : Il faut récupérer le pays d'appartenance du vendeur. On le récupère dans l'ordre par : o Le pays défini dans l'adresse de paiement du vendeur o Le pays défini dans l'adresse bancaire de compensation du vendeur o Le pays d'expédition défini au niveau compte vendeur Pour les vendeurs particuliers membres de la CEE hors France ou Espagne, on indique le pays de la maison mère Babelstore à savoir : la France. Pour les vendeurs particuliers hors CEE, qui sont exemptés de TVA, on indique comme pays par défaut la France. Pour les vendeurs professionnels hors France et Espagne, qui sont exemptés de TVA, on indique le pays de la maison mère Babelstore à savoir : la France. Cordialement, Agathe |
| Commentaire de Agathe Remy [ 13/avr./07 16:52 ] |
|
Philippe, As-tu eu le temps de valider le nouveau rapport? Peut-on supprimer l'ancien dans BI? Merci:-) Agathe |
| Commentaire de Philippe Favrot [ 16/avr./07 18:27 ] |
|
Agathe, J'ai commencé mais pas fini :-( C'est Claudie qui va gérer la fin de ce dossier ; je viens de passer 1/2 heure avec elle pour la briefer et lui donner tous les éléments en ma possession. On te revient donc rapidement. Merci Philippe |
| Commentaire de Philippe Favrot [ 24/avr./07 11:24 ] |
|
Bonjour Agathe, des anomalies mises en évidence, mais qui s'expliquent probablement en partie par le fait que sur le mois de février ont coexisté à la fois l'ancien et le nouveau système de gestion de la TVA. Pour valider ce point nous avons besoin que tu nous sortes les rapports identiques pour le mois de mars. Merci Philippe |
| Commentaire de Agathe Remy [ 26/avr./07 19:06 ] |
|
Les fichiers des transactions exemptées de TVA France et de
toutes les transactions Espagne créées en mars 2007 ont été générés et
attachés au JIRA. Cordialement, Agathe |
| Commentaire de Claudie Dufresne [ 04/mai/07 18:35 ] |
|
Agathe, Sur les fichiers de mars, on a constaté les anomalies suivantes concernant les transactions France uniquement : 1- Particuliers exonérés de TVA alors que le pays de référence est chaque fois la France, 3 sellers account, cf ci-dessous : 57947926 12430583 FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN INDIVIDUAL GAMES 19,6 58621686 12430583 FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN INDIVIDUAL GAMES 19,6 58634397 12430583 FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN INDIVIDUAL GAMES 19,6 59777727 13802080 FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN INDIVIDUAL CONSOLE 19,6 59785427 12430583 FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN INDIVIDUAL GAMES 19,6 2- Professionnels exonérés de TVA alors que le pays de référence est chaque fois la France, 1 seller account, cf ci-dessous : 58520202 1097015 FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN PRO COMPONENT 19,6 58596060 1097015 FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN PRO STORAGE 19,6 Peux-tu nous dire s'il y a une explication, Merci à toi claudie |
| Commentaire de Agathe Remy [ 09/mai/07 10:44 ] |
|
Bonjour Arnaud, Peux-tu répondre à Claudie? Je suis à ta dispo si tu as besoin de précisions. Merci:-) Agathe |
| Commentaire de Arnaud Forgues [ 09/mai/07 14:57 ] |
|
Agathe, Claudie, Voici les raisons de ces "anomalies" qui n'en sont pas en fait ! : - le pays de la transaction qui est défini comme l'a décrit Agathe précédemment, est stocké lors de la mise en panier de l'article, . - cela n'a donc pas de sens d'extraire les pays de paiement, de compensation et d'expédition en plus du pays de la transaction afin de vérifier la bonne application des règles de gestion, car ceux-ci ont pu changer entre la mise en panier de l'article (calcul du pays de transaction) et l'extraction du rapport BI. - Afin de faire tout de même cette vérification (si vous y tenez), il faudrait archiver les pays de paiement, compensation et expédition au moment de la mise en panier de l'article, ce qui n'est pas le cas actuellement ==> DEV - J'ai pu vérifié cette hypothèse sur 2 des 3 vendeurs ci-dessus : * 12430583 : marubozu était Suisse (j'ai pu le vérifier sur le site d'integ qui date de mi mars) avant de passer Francais au niveau du pays de paiement * 13802080 : est Francais actuellement mais a créé son compte après la mise à jour du site d'integ, du coup je ne peux pas vérifier qu'il était non francais lors de la mise en panier de l'article 59777727. De plus il n'a pas fait d'autre vente depuis. Mais on pourra vérifier lors de sa prochaine vente qu'on lui applique bien la TVA francaise * 1097015 : 1097015 était Luxembourgeois (vu en integ) avant de passer Francais. Malheureusement, on n'a pas d'évenement nous permettant de tracer ces changements de pays (excepté une date de modification qui est en place depuis la V14 mais qui n'est pas suffisante pour ce ce genre de pb). Et donc si cela est nécessaire cela nécessite du DEV. Voilou. Si vous avez besoin de plus d'explications, n'hésitez pas à venir me voir. Je retransmet donc le JIRA à Agathe pour la suite des évenements ! Arnaud |
| Commentaire de Philippe Favrot [ 10/mai/07 17:36 ] |
|
Arnaud, merci pour ces explications c'est très clair pour nous. Je ne pense pas qu'il faille faire du dev pour archiver les changements de pays. En revanche, Claudie va faire un Jira à l'Equipe d'Agathe pour qu'on ait les moyens d'obtenir tous les mois la liste des transactions exonérées de TVA ; on conservera de notre côté le résultat de ces requêtes qu'on pourra produire en cas de contrôle de la part de l'administration fiscale (on aura simplement en anomalie les éventuels changements de pays entre la date de mise en panier et le début du mois suivant ; donc peu important). Fred, je pense que tu peux à présent fermer ce Jira. Merci Philippe |
[cob] META-TACHE Fermeture Epik
(APP-25109)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 53.0.4 |
| Type: | Sous-tâche | Priorité: | Mineur |
| Rapporteur: | Fabrice Feugas | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM: | *** RESERVE *** |
| Description |
|
Nettoyer le code côté BI des cobs cités dans le titre et qui ont été arrêtés.
|
| Commentaires |
| Commentaire de Agathe Remy [ 30/avr./09 11:42 ] |
| Intégration des emails dans le flux Pn Data prévue pour le flux mensuel du 02/07 |
| Commentaire de Fabrice Feugas [ 28/sept./09 12:10 ] |
| Cyril, ce JIRA n'a plus lieu d'être ouvert non? |
| Commentaire de Cyril Tanneau [ 28/sept./09 12:21 ] |
|
Fabrice, Les membres ont en effet été intégrés au flux mensuel PNDATA à la date prévue (début Juillet) On peut fermer le JIRA, Merci, Cyril |
[cob] META-TACHE Fermeture LeProgrès
(APP-28357)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 69.0.1.1 |
| Type: | Sous-tâche | Priorité: | Mineur |
| Rapporteur: | Fabrice Feugas | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM: | *** RESERVE *** |
| Description |
|
Nettoyer le code côté BI des cobs cités dans le titre et qui ont été arrêtés.
|
| Commentaires |
| Commentaire de Fabrice Feugas [ 19/avr./10 12:23 ] |
| A priori c'est ok ce JIRA non ? |
[EXP-1482] BI : création d'un user babel_bi sur GLOB de Jupiter Création: 09/mars/06 11:41 Mise à jour: 25/juin/07 18:56 Résolue: 29/mars/06 17:29 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Nouvelle fonctionnalité | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | Edouard Laurent |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
test_prod.sql
|
| Description |
|
Bonjour, Nous avons essayé de connecter notre alimentation du Datawarehouse BI sur la standby de Mercure. Or il semble que les droits que nous avons sur une standby en read-only ne sont pas suffisants pour permettre cette alimentation. Nous avons alors adopté une solution provisoire qui consiste à alimenter le datawarehouse à partir de Titan. Or cette solution nous oblige à attendre la fin de la synchronisation pour commencer l'alimentation du Datawarehouse sur Latone, ce qui amène la fin de notre alimentation à 11h AM. L'application BI n'est donc pas à jour avant cette heure-là. Nous aimerions donc lancer notre alimentation directement à partir de la base GLOB de Jupiter. Nous la programmerions à 2h AM afin de perturber le moins possible le site. Le chargement des données dure environ 1/2 heure. Afin de le faire de façon sécurisée, nous aimerions que vous nous créiez un user babel_bi qui n'aurait que des droits en lecture (SELECT) sur les synonymes de babel_1. Je reste à votre disposition pour toute question. Merci:-) |
| Commentaires |
| Commentaire de Sébastien Tournay [ 09/mars/06 12:41 ] |
|
Edouard, Je te laisse faire le point avec DIB pour mettre cela en place. |
| Commentaire de Edouard Laurent [ 14/mars/06 10:40 ] |
|
Je pense que faire l'allimentation du DW depuis Jupiter est
une mauvaise idee car cela va a l'encontre des objectifs de
disponibilite du site que nous nous sommes fixes et ce n'est pas
compatible avec les deploiements. Je vous propose plutot d'essaye de resoudre le probleme d'allimentation depuis une standby. Etant donne que le chargement est rapide ( ~ 1/2h ) on peut imaginer ouvrir une standby pendant une periode pour etre exactement dans la meme configuraiton que jupiter. Je vais voir avec D Blanc si ce n'est pas trop complique d'ouvir sur un creneau d'une heure ou deux la nuit. |
| Commentaire de Agathe Remy [ 14/mars/06 12:09 ] |
| Dans ce cas, il faut que tu trouves le bon paramétrage à appliquer à la standby en read-only pour que l'exécution de cette requête à partir de l'ODS sur Titan fonctionne:-) |
| Commentaire de Edouard Laurent [ 17/mars/06 11:58 ] |
|
Je ne trouve pas de solution en 9i, il faudra attendre la 10g pour alimenter le DW depuis une standby. On va donc utiliser la base OLTP. Pour cela je vais creer un utilisateur qui a uniquement les droits de "select" sur les tables de "babel_1" (ou plutôt les synonymes). Il faut integrer dans le processus de deploiment, l'interdiction de se connecter a ce user pendant les deploiements pour eviter au maximun les problemes. |
| Commentaire de Edouard Laurent [ 22/mars/06 10:38 ] |
|
Didier a cree le user hier, il faut tester maintenant la procedure d'alimentation de DW depuis GLOB. Attention de bien me prevenir avant de planifier ou lancer la prodedure d'alimentation. Il faudra surveille la charge de la base et la disponibilite du site les premieres fois et etre bien sur que ca ne va pas se derouler en meme temps qu'un deploiement ou un mini deploiement. Merci |
[EXP-4616] [BI] : Problèmes de lenteur dans l'accès à bi.priceminister.com Création: 14/nov./08 14:49 Mise à jour: 24/févr./09 16:35 Résolue: 24/févr./09 16:35 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Troubleshooting |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Agathe Remy | Attribution: | Patrice Boulanger |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour Patrice, Régulièrement, l'accès à l'application bi.priceminister.com connaît des lenteurs pénalisantes pour l'utilisation de l'application : temps de connexion très long, affichage des pages ou téléchargement de l'applet durant plusieurs minutes, ... Il me semble que cela ne vient pas du serveur BusinessObjects (ou de l'applicatif) puisque elasippos est très peu chargé (moins de 1 de charge, même lors de ces problèmes). Je me demande donc si cela provient du réseau ou bien du serveur front Web par lequel nous passons. Nous avons de plus en plus de remontées de nos utilisateurs sur ce problème que nous ne savons pas comment traiter. S'il te plait, pourrais-tu nous aider d'où proviennent ces lenteurs et voir comment y remédier? Merci. Agathe |
| Commentaires |
| Commentaire de Patrice Boulanger [ 24/févr./09 16:35 ] |
|
Les problèmes de lenteur réseau sont résolus suite à la
suppression d'une ACL limitant la BP vers certains serveurs web. Je clos le jira. Merci. |
[BIN-477] Changement de destinataire es rapports BI Création: 25/août/08 18:37 Mise à jour: 02/sept./08 19:02 Résolue: 28/août/08 18:58 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Henrieta Bubenkova | Attribution: | Dalila Belkebir |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Suite à mon départ au 31/08/08 je voudrais demander un changement de destinataire pour tous les rapports BI qui sont actuellement envoyés à mon adresse e-mail. Pourriez-vous les envoyer désormais à Ghislain Gridel: ghislain.gridel@priceminister.com qui me remplacera sur toute la partie Comparateurs et egalement à Jean-Michel Salem qui s'occupe de la gestion opérative des Comparateurs. Merci d'avance! Henrieta |
| Commentaires |
| Commentaire de Dalila Belkebir [ 28/août/08 18:58 ] |
|
Bonjour Henrieta, C'est fait pour les rapports suivants : Fideliplus Clubic - Appel à facture mensuel Pangora - Appel à facture mensuel Partner - Weekly revenue by tracking group Appel à facture sur volume d'affaires par groupe de tracking Appel à facture sur CA par groupe de tracking Dalila. |
[BIN-131] Création d'un rapport acheteurs sous BI Création: 11/août/06 15:19 Mise à jour: 14/sept./07 17:18 Résolue: 02/oct./06 12:41 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Alexandra Viravaud | Attribution: | Agathe Remy |
| Résolution: | Aucune correction envisagée | ||
| Estimation restante: | 2 heures | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | 2 heures | ||
| Description |
|
Salut Mohammed, je souhaiterais programmer un nouveau rapport acheteurs sous BI portant sur les indications suivantes : - Nb d'acheteurs depuis 1 mois - Nb d'acheteurs depuis 12 mois - Nb d'acheteurs depuis le debut Si tu peux passer pour qu'on fasse ca ensemble. Merci Alexandra |
| Commentaires |
| Commentaire de Alexandra Viravaud [ 02/oct./06 12:36 ] |
| merci d'annuler cette demande. |
[INF-535] [BI] : Arrivée de Valeria GUSA le 20/09/2010 Création: 02/sept./10 16:00 Mise à jour: 03/nov./10 12:41 Résolue: 03/nov./10 12:41 |
|
| Etat: | Résolu |
| Projet: | Infrastructure |
| Composants: | Arrivée/Départ |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | Christophe Garcia |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
FICHE NOUVEL ARRIVANT VGU.doc
|
| Description |
|
Bonjour, Valeria GUSA rejoint l'équipe BI en CDI le 20 septembre 2010. Toutes les infos sont dans la fiche nouvel arrivant ci-jointe. Je dois encore définir son emplacement la semaine prochaine. A ta dispo si tu as besoin d'autres infos. Merci, Agathe |
| Commentaires |
| Commentaire de Agathe Remy [ 02/sept./10 16:01 ] |
| Son trigramme sera VGU. |
| Commentaire de Stéphane Eccli [ 16/sept./10 11:03 ] |
| comptes créés, reste Jira |
[BIN-681] [BuyBox]Etudes BI pre-projet Création: 06/juil./10 15:12 Mise à jour: 02/sept./10 15:51 Résolue: 28/juil./10 14:13 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Thomas Allier | Attribution: | Thomas Allier |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Les analyses souhaités en amont de la sortie du projet BuyBox sont les suivantes:  Répartition des vendeurs par tranche de taux de claim  Répartition des vendeurs par tranche de taux d'acceptation  Répartition des vendeurs par tranche de note  Répartition des premières ventes par tranche de prix Selon disponibilité de l'équipe BI, une finesse d'analyse par type de produit aurait un intérêt pour les 3 premières études. |
| Commentaires |
| Commentaire de Thomas Allier [ 27/juil./10 18:14 ] |
| Fait : Répartition des vendeurs par tranche de taux d'acceptation |
| Commentaire de Thomas Allier [ 28/juil./10 10:28 ] |
| Fait : Répartition des vendeurs par tranche de note |
| Commentaire de Thomas Allier [ 28/juil./10 11:23 ] |
| Fait : Répartition des vendeurs par tranche de taux d'acceptation |
| Commentaire de Thomas Allier [ 28/juil./10 14:13 ] |
|
Prix des premières ventes OK. J'ai tout ce qu'il me faut |
[EXP-1399] bi : je voudrais avoir acces a la plateforme bi de chez moi avec mon adresse ip fixe Création: 28/févr./06 09:37 Mise à jour: 25/juin/07 18:56 Résolue: 20/mars/06 16:22 |
|
| Etat: | Fermé |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Justin Ziegler | Attribution: | Sébastien Tournay |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
quels sont les fichiers de conf impacte ? NB : j'ai deja rajoute mon adresse IP dans la config HTTP, mais cela ne semble pas etre sufisant. |
| Commentaires |
| Commentaire de Sébastien Tournay [ 20/mars/06 15:13 ] |
|
En principe cela doit être suffisant. Je viens de vérifier
la conf sur CUPIDON et PHAETON. Ton @IP est bien ajoutée au virtual-host
bi. Il n'est pas question non plus de .htacess pour ce virtual-host et
la VIP utilisée (.8) est la même que bo.priceminister.com donc au niveau
du FireWall de JMH c'est bon. Tu peux ressayer à nouveau pour voir si il ya du changement sur l'accès ? |
| Commentaire de Justin Ziegler [ 20/mars/06 15:46 ] |
|
Oui, c bon depuis quelques temps. En fait j'avais fait une erreur dans la saisie de l'adresse sur l'un des serveurs. on peut fermer ce jira. |
[BIN-515] [BI Souhaits] : Evolution des rapports de souhaits Création: 13/nov./08 10:45 Mise à jour: 22/déc./10 17:46 Résolue: 22/déc./10 17:46 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | CRM |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Thomas Beylot | Attribution: | Julien Girardet |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour Ainsi que vu ensemble lors de notre dernier point bimensuel il faut apporter des évolutions aux deux rapports servis pour : - faciliter l'utilisation que le service marketing peut faire de ces rapports pour établir une analyse et un reporting - servir des données conformes à l'habitude prise de faire des reporting "mensuels" premier point : faciliter l'analyse de l'historique à l'instar des rapports SLTV on observe qu'il est compliqué de sortir les rapports sur tout l'historique. Aussi il serait bien de faire ce travail en amont et de déposer les rapports sur un dossier partagé. deuxième point : améliorer les performances des rapports pour une utilisation fréquente troisième point : améliorer la forme des rapports ainsi que vu ensemble, le rapport "user distribution..." devrait permettre de sortir plusieurs mois sur le même rapport, afin de mesurer la variation de la distribution sur une période définie. sur l'autre rapport (décliné en deux versions) ce serait bien d'avoir le mois renseigné en colonne, pour avoir un rapport qui serait du type : Product family Day month wish owner New wish owner wish Created wish Closed wish Deleted wish Notified Captured GMS BOOKS 2001/04/12 2001/04 4 4 8 0 0 0 0.00 GAMES 2001/04/12 2001/04 1 1 1 0 0 0 0.00 MUSIC 2001/04/12 2001/04 4 4 8 0 0 0 0.00 VIDEO 2001/04/12 2001/04 3 3 3 0 0 0 0.00 quatrième point : "mensualiser" les rapports Actuellement, soit on sort les datas sur une période donnée mais on n'a pas le détail de la période (agglomération des données) soit on sort les datas par jour et on retraite (pour avoir le mois par exemple) mais du coup les datas ne sont pas dédupliquées Il faut donc que lorsque je souhaite avoir le nombre de souhaiteurs sur décembre 2007, je n'ai que le nombre de souhaiteurs uniques, par exemple. A qui j'associe le nombre de souhaits exact... etc. Enfin, je note que sur le rapport de distribution des souhaits je ne peux pas avoir sur une période le nb de souhaits actifs mais seulement le nb de souhaits déposés sur la période (enfin, on pourrait l'avoir mais ça coute cher). Merci Thomas. |
| Commentaires |
| Commentaire de Agathe Remy [ 13/nov./08 18:59 ] |
|
Thomas, Pour info, nous sommes hyper chargés jusqu'à fin janvier 2009, notamment avec le BI Abonnement et le BI UK. Heureusement, nous avons prévu un créneau en Q1 2009 pour traiter ces évolutions. A ta dispo pour en discuter. Agathe |
| Commentaire de Dalila Belkebir [ 18/sept./09 18:17 ] |
|
Bonjour Carole, Comme vu avec Thomas, peux-tu regarder ce JIRA et mettre à jour la demande en terme de contenus et priorisation ? Merci d'avance. Cdlt, Dalila. |
| Commentaire de Julien Girardet [ 22/déc./10 17:46 ] |
|
doublon avec le JIRA |
[cob] META-TACHE Fermeture Dauphiné Libéré et CamifOccasion
(APP-25678)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 61.0.0 (CTN-O) |
| Type: | Sous-tâche | Priorité: | Mineur |
| Rapporteur: | Fabrice Feugas | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM: | *** RESERVE *** |
| Description |
|
Nettoyer le code côté BI des cobs cités dans le titre et qui ont été arrêtés.
|
| Commentaires |
| Commentaire de Fabrice Feugas [ 18/nov./09 11:35 ] |
| Cyril, t'as une idée sur quand sera planifiée cette tâche ? |
| Commentaire de Fabrice Feugas [ 18/nov./09 12:11 ] |
| Déjà fait. |
[BIN-655] [MKT] Historique rapport BI "Daily item follow up by advert tracking and product family" Création: 24/févr./10 10:46 Mise à jour: 05/mars/10 17:57 Résolue: 05/mars/10 16:32 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Audrey Angleys | Attribution: | Dalila Belkebir |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Hello, Comme discuté, je souhaiterais retrouver l'historique (depuis janvier 2008) de ce rapport BI: Item / Daily item follow up by advert tracking and product family, qui me permet de suivre les ventes trackées. Idéalement, si on pouvait également avoir ce rapport en mensuel, cela éviterait d'avoir des fichiers excel trop lourds... Merci beaucoup, Audrey |
| Commentaires |
| Commentaire de Dalila Belkebir [ 25/févr./10 15:41 ] |
|
Audrey, Ton extract tu la veux maintenant au format date ou mois ? Tu la veux sur quels groupes de tracking annonces? Cdlt, Dalila. |
| Commentaire de Audrey Angleys [ 25/févr./10 16:31 ] |
|
Dalila, Oui si je pouvais avoir l'extract au format mois, ce serait parfait. Voici les groupes de tracking que je suis plus particulièrement: - Automatisation - PL-Maison - PL-Mode - PL-high-tech - PL-culturelle - Post-clic - Priceletterx - Priceletter-VF - Priceletter-vente Merci beaucoup! Audrey |
| Commentaire de Dalila Belkebir [ 05/mars/10 16:32 ] |
|
Audrey, Je suis en cours de génération de l'historique comme demandé. Tu trouveras les fichiers sur le serveur All_PM et dans le répertoire : BI\02 - Historiques de données\2010-03 Monthly item follow up by advert tracking and product family Les données ne sont pas triées et seront réparties sur 4 fichiers (un par semestre). Merci de me confirmer que cela te convient. Cdlt, Dalila. |
| Commentaire de Audrey Angleys [ 05/mars/10 16:45 ] |
|
Merci beaucoup Dalila, c'est exactement ça! Merci Audrey |
| Commentaire de Dalila Belkebir [ 05/mars/10 17:57 ] |
|
OK audrey. Je ferme donc le JIRA. Cdlt, Dalila. |
[BIN-397] [Label vendeur] : url label vendeur dans BI Création: 20/déc./07 11:22 Mise à jour: 21/déc./07 18:12 Résolue: 20/déc./07 12:36 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Ghislain Gridel | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Salut Agathe, peux-tu rajouter l'url des sites qui ont intégrés le labels vendeurs dans BI, stp ? Merci ! Ghislain |
| Commentaires |
| Commentaire de Agathe Remy [ 20/déc./07 12:36 ] |
|
Ghislain, Le label vendeur a été ajouté dans l'univers FRANCE - USER ACCOUNT. Tu le trouveras dans la classe User Account sous le nom Seller website URL. Agathe |
| Commentaire de Ghislain Gridel [ 20/déc./07 14:19 ] |
| merci |
[BIN-296] données manquante sur résultats newsletter à 30j dans BI Création: 26/févr./07 14:11 Mise à jour: 14/sept./07 18:02 Résolue: 26/févr./07 15:35 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Charlotte Fachan | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Salut Agathe, dans BI je n'arrive pas à retrouevr les données relatives à la newsletter Pl-maison34-soldesmarques le code de tracking associé est 1708041 et le groupe de tracking sous lequel tout cela a été enregistré : Post-Clic Sur BI, dans purchase by purchase tracking, pas d'infos (VA, com, paniers....)? Cette news aurait-elle disparue du reporting? Comment récupérer ces chiffres? Merci Charlotte |
| Commentaires |
| Commentaire de Agathe Remy [ 26/févr./07 14:23 ] |
|
Charlotte, Sur quelle période as-tu rafraîchi le rapport? Merci:-) Agathe |
| Commentaire de Agathe Remy [ 26/févr./07 14:34 ] |
|
En fait, le nom à la création de ce tracking était : post-clic-DVD. Comme il n'y a pas de suivi des modifications de cette table, le nom mis à jour sur le site n'est pas mis à jour dans la base de reporting. Tes données sont donc celles du tracking post-clic-DVD. Cordialement, Agathe |
| Commentaire de Charlotte Fachan [ 26/févr./07 14:37 ] |
|
euh... du 23/01/07 au 23/02/07! merci Charlotte |
| Commentaire de Charlotte Fachan [ 26/févr./07 14:43 ] |
|
oui le nom a été modifié en effet... Cela signifie-t-il que les données de cette news sont mélangées aux résultats post-clic DVD???? |
| Commentaire de Agathe Remy [ 26/févr./07 14:53 ] |
|
Bah oui... Sinon fallait créé un nouveau tracking?! Agathe |
| Commentaire de Agathe Remy [ 26/févr./07 15:35 ] |
|
C'est bon : j'ai mis à jour les libellés de tracking dans la base de reporting. J'ai vérifié qu'il n'y avait pas de panier avant le 23/01/2007 associé au tracking PL M&L. Tout semble donc OK. D'autre part, je vais voir avec l'équipe Dév comment tracer vos modifications de libellé de tracking... Agathe |
[BIN-642] Il y a plus de paniers authorisés qui remontent chez le partenaire que sur BI Création: 23/déc./09 15:48 Mise à jour: 28/déc./09 17:50 Résolue: 28/déc./09 17:24 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Bloquant |
| Rapporteur: | Jonathan Gorges | Attribution: | Dalila Belkebir |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Match panier effiliation 2.xls
|
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Nous rencontrons un problème entre les données BI et les données plateforme chez Effiliation. En effet, nous remontons plus de paniers autorisés via le tag Effiliation (trackés effilaition) sur l'extranet de la plateforme que le nombre de paniers autorisés présents dans l'export bi. Exemple pour la journée du 10/12/2009 nous obtenons: Sur l'extranet plateforme: 1950 paniers authorisés. Sur l'export : dans l'univers Purchase > Weekly purchase overview (30 days tracking) : groupe Affiliationx: 1383 paniers authorisés. Soit un manque de 557 paniers sur BI. L'appel du tag est conditionné à la présence d'un tracking du groupe Affiliationx; nous ne voyons donc pas comment cela est possible de se retrouver dans cette situation. Nous vous mettons en pièce jointe les différentes données dans le fichier: Match panier Effilaiton.xls Voici le descriptif des onglets: Extract plateforme: donner plateforme Extract BI: Recherv : la recherche sur les planiers plateformes de l'équivalent panier sur bi Recherv coller en valeur: l'onglet précédent copier en valeur= paniers qui ne sont pas dans BI: liste des paniers présents sur l'extranet plateforme mais qui ne le sont pas dans BI. Merci pour votre retour sur ce sujet alarmant |
| Commentaires |
| Commentaire de Dalila Belkebir [ 23/déc./09 15:54 ] |
|
hello Jonathan, Je ne vois pas de PJ sur le JIRA. As-tu déjà regardé ce point avec Mathilde car nous avons déjà dû regarder un écart sur le groupe Affiliationx ou affliquelquechose (attention au paramétrage des groupes/tracking name) ? Les paniers remontés via le tag sont bien autorisés ? non abandonnés (paniers créés mais non validés par le user)? Le sujet n'est pas alarmant tant que le pb n'a pas été clairement identifié. Une fois le pb identifié nous pourrons le qualifier. Pour le moment je ne vois que l'urgence de vérifier cet écart. A ta dispo, Dalila. |
| Commentaire de Dalila Belkebir [ 28/déc./09 17:24 ] |
|
Bonjour Jonathan, Comme vu ensemble le pb ne se situe pas au niveau des données, qui sont celles enregistrées dans le système. Pourrais-tu STP préciser d'où vient le pb au final (taggage des paniers ?)? As-tu pu voir la manip à faire côté paramétrage afin de corriger le pb? merci de ton retour pour clôture du JIRA. cdlt, Dalila. |
| Commentaire de Jonathan Gorges [ 28/déc./09 17:34 ] |
|
Hello, Le problème semble avoir été résolu. Je ne sais pas encore comment... Vous pouvez fermer le Jira. Merci pour votre aide. Bonne journée. Jonathan. |
[INF-91] BI : arrivée de Dalila le 1er juillet 2008 Création: 18/juin/08 15:44 Mise à jour: 07/juil./08 15:24 Résolue: 07/juil./08 15:24 |
|
| Etat: | Fermé |
| Projet: | Infrastructure |
| Composants: | Arrivée/Départ |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Agathe Remy | Attribution: | Christophe Garcia |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
FICHE NOUVEL ARRIVANT DBE.doc
|
| Description |
|
Bonjour, Notre chef de projet BI arrive le 1er juillet 2008. Dans un premier temps, elle prendra le poste de Florian AMBROSI qui termine son stage le 30 juin, puis elle s'installera à la place de Romain à partir du 24 juillet. Toutes les autres infos sont dans la fiche nouvel arrivant ci-jointe. A ta dispo si tu as besoin d'autres infos. Merci. Agathe |
| Commentaires |
| Commentaire de Stéphane Eccli [ 01/juil./08 14:20 ] |
|
compte reseau et mail ok reste Jira |
| Commentaire de Christophe Garcia [ 07/juil./08 15:24 ] |
| JIRA OK |
[APP-19182] BI: Création de la CHANGE_DATE sur usr_message Création: 16/janv./08 16:40 Mise à jour: 04/févr./08 15:30 Résolue: 21/janv./08 15:49 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Base de données |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 19.0.0 |
| Type: | Nouvelle fonctionnalité | Priorité: | Critique |
| Rapporteur: | Romain Czornomaz | Attribution: | Renaud Dierickx |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
screenshot-1.jpg
|
| Pays: |
ALL - Tous
|
| Site: | Prod |
| Projets PM archivés: | Maintenance 19.x.x |
| Description |
|
Bonjour, Dans le cadre de la mise en place du BI Backoffice pour Q1 2008, nous avons à importer les différents éléments liés aux messages utilisateurs. Le backoffice est ammené à modifier le contenu des enregistrements lors du traitement des messages. Or, actuellement la table ne possède pas de CHANGE_DATE indispensable de notre coté pour effectuer des chargements incrémentaux avec les enregistrements modifiés. Serait-il possible de planifier cette évolution de l'application pour les prochaines versions du site? Merci d'avance, Romain |
| Commentaires |
| Commentaire de Nicolas Chauveau [ 17/janv./08 15:58 ] |
| Verifier le besoin : creation_date / change_date |
| Commentaire de Renaud Dierickx [ 21/janv./08 15:46 ] |
|
C'est fait et testé sur le tronc. J'affiche la change_date en infobulle lorsqu'on met le curseur sur la creation_date : - sur l'écran de recherche d'un message - sur l'écran de recherche de configuration du message (voir screenshoot) |
| Commentaire de Espérance Galouo-Lece [ 04/févr./08 15:30 ] |
| Done. |
[EXP-3482] BI : problème de temps d'alimentation du Datawarehouse sur Latone Création: 12/avr./07 14:16 Mise à jour: 14/avr./08 17:56 Résolue: 14/avr./08 17:56 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Agathe Remy | Attribution: | Patrick Pereira |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Nous avons modifié la clause de sélection des données de la veille sur les tables chargées en incrémentales le 11/04/2007. Pour le chargement des données de la table ITEM de jupiter vers latone, les temps de traitements sont passés de 700 secondes en moyenne à plus de 8000 secondes:-( Le plan d'exécution de l'ancienne requête fait un FULL scan de la table alors que la nouvelle passe par l'index ITEM_IX qui n'a pas été analysé depuis le 05/10/2006... C'est la première fois que je vois un full scan plus rapide que le passage par un index?! En attendant l'intervention d'un DBA expérimenté sur la base de production du site, nous avons remis l'ancienne condition... Agathe |
| Commentaires |
| Commentaire de Patrick Pereira [ 25/avr./07 14:35 ] |
| Peux-tu me donner la condition que tu as utilisée pour le 11/04/2007 ? |
| Commentaire de Agathe Remy [ 25/avr./07 14:46 ] |
|
cible : (ITEM.CREATION_DATE >= TRUNC(sysdate-2) OR ITEM.CHANGE_DATE >= TRUNC(sysdate-2) ) AND ITEM.CREATION_DATE < TRUNC(sysdate) actuellement : (ITEM.CREATION_DATE >= TRUNC(sysdate-2) AND ITEM.CREATION_DATE < TRUNC(sysdate) ) OR ITEM.CHANGE_DATE >= TRUNC(sysdate-2) |
| Commentaire de Patrick Pereira [ 15/janv./08 12:17 ] |
|
La requête actuelle à la forme suivante : SELECT /*+ OPAQUE_TRANSFORM */ ITEM_ID,BUYER_ACCOUNT_ID,SELLER_ACCOUNT_ID,CREATION_DATE,CHANGE_DATE,ADVERT_ID,PURCHASE_ID,ITEM_COST_PRICE,ITEM_COMMISSION_TAX_RATE,SHIP_COST_PRICE,SHIP_COMMISSION_TAX,SHIP_COMMISSION_TAX_RATE,SHIPPING_TYPE_ID,RETURN_SHIPPING_PRICE,CURRENCY_ID,BUYER_COMMENT ,SELLER_SCORE,ITM_STATUS_CODE,CLOSING_DATE,COMPENSATION_ID,COMPENSATION_PROCESSING_DATE,IS_ABANDONNED,BUYER_BONUS,SELLER_BONUS,CLAIM_COMPENSATION_ID,ITM_CLAIM_TYPE_CODE,CLAIM_COMMENT,LAST_CLAIM_DATE,CLM_STATUS_CODE,HISTORY,BUYER_REMIND_CODE,SELLER_REMIND_CODE,BUYER_REMIND_DATE, SELLER_REMIND_DATE,ORIGIN_SCREEN,ORIGIN_BLOCK,PRODUCT_ID,SELLER_COUNTRY_ID,SELLER_LOGIN,ADV_QUALITY_CODE,ADV_SELLER_COMMENT,ADV_SERIAL_NUMBER,PRD_TYPE_CODE,PRD_MEDIUM_CODE,PRD_LIST_PRICE,PRD_CURRENCY_ID,COMMIT_DATE,CLAIM_CLOSING_DATE, FEEDBACK_DATE,BUYER_LOGIN,ADV_SELLER_REFERENCE1,ADV_IS_ORIGINAL,ADV_TYPE_CODE,ADV_SELLER_PRIVATE_COMMENT,PRD_LINE_KEY,PRD_MODEL_KEY,SELLER_JUSTIFICATION,ITEM_FIXED_COMMISSION_NET,ITEM_FIXED_COMMISSION_TAX,ITEM_VARIA_COMMISSION_NET,ITEM_VARIA_COMMISSION_TAX,SHIP_COMMISSION_NET,COMMISSION_ID ,ITM_TYPE_CODE,ITM_CANCEL_CODE,ADV_SALE_PRICE,ADV_CURRENCY_ID,BUYER_NEGOTIATION_COMMENT,SHIPMENT_NUMBER_1,SHIPMENT_NUMBER_2,COMPLEMENT_PRODUCT_ID,SHIPPING_SIZE_ID,ADV_ALLOW_SHIPPING,ADV_ALLOW_PICKUP,ADV_PICKUP_PHONE_NUMBER,ADV_PICKUP_ZIP,ADV_PICKUP_COUNTRY_ID,IS_SELLER_VAT_EXEMPTED, VAT_COUNTRY_ID,VAT_DISCLAIMER,SELLER_NEGO_PRICE,IS_CBV_APPLICABLE FROM ITEM WHERE "CHANGE_DATE">=TRUNC(sysdate-2) OR "CREATION_DATE">=TRUNC(sysdate-2) AND "CREATION_DATE"<TRUNC(sysdate); Son coût et plan sont les suivants : -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 167K| 173M| 813K (1)| 02:42:45 | |* 1 | TABLE ACCESS FULL| ITEM | 167K| 173M| 813K (1)| 02:42:45 | -------------------------------------------------------------------------- Statistics ---------------------------------------------------------- 15 recursive calls 0 db block gets 2989175 consistent gets 2562277 physical reads 0 redo size 66707284 bytes sent via SQL*Net to client 163846 bytes received via SQL*Net from client 14852 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 222756 rows processed Je te propose de créer les deux indexes suivants : - ITM_IX_CREATION_DATE ( trunc(creation_date)) - ITM_IX_CHANGE_DATE ( trunc(change_date), trunc(creation_date)) La requête devient alors (j'en profite pour ajouter des '(' pour être sûr du comportement) : SELECT "ITEM_ID","BUYER_ACCOUNT_ID","SELLER_ACCOUNT_ID","CREATION_DATE","CHANGE_DATE","ADVERT_ID","PURCHASE_ID","ITEM_COST_PRICE","ITEM_COMMISSION_TAX_RATE","SHIP_COST_PRICE","SHIP_COMMISSION_TAX","SHIP_COMMISSION_TAX_RATE","SHIPPING_TYPE_ID","RETURN_SHIPPING_PRICE","CURRENCY_ID","BUYER_COMMENT" ,"SELLER_SCORE","ITM_STATUS_CODE","CLOSING_DATE","COMPENSATION_ID","COMPENSATION_PROCESSING_DATE","IS_ABANDONNED","BUYER_BONUS","SELLER_BONUS","CLAIM_COMPENSATION_ID","ITM_CLAIM_TYPE_CODE","CLAIM_COMMENT","LAST_CLAIM_DATE","CLM_STATUS_CODE","HISTORY","BUYER_REMIND_CODE","SELLER_REMIND_CODE","BUYER_REMIND_DATE", "SELLER_REMIND_DATE","ORIGIN_SCREEN","ORIGIN_BLOCK","PRODUCT_ID","SELLER_COUNTRY_ID","SELLER_LOGIN","ADV_QUALITY_CODE","ADV_SELLER_COMMENT","ADV_SERIAL_NUMBER","PRD_TYPE_CODE","PRD_MEDIUM_CODE","PRD_LIST_PRICE","PRD_CURRENCY_ID","COMMIT_DATE","CLAIM_CLOSING_DATE", "FEEDBACK_DATE","BUYER_LOGIN","ADV_SELLER_REFERENCE1","ADV_IS_ORIGINAL","ADV_TYPE_CODE","ADV_SELLER_PRIVATE_COMMENT","PRD_LINE_KEY","PRD_MODEL_KEY","SELLER_JUSTIFICATION","ITEM_FIXED_COMMISSION_NET","ITEM_FIXED_COMMISSION_TAX","ITEM_VARIA_COMMISSION_NET","ITEM_VARIA_COMMISSION_TAX","SHIP_COMMISSION_NET","COMMISSION_ID" ,"ITM_TYPE_CODE","ITM_CANCEL_CODE","ADV_SALE_PRICE","ADV_CURRENCY_ID","BUYER_NEGOTIATION_COMMENT","SHIPMENT_NUMBER_1","SHIPMENT_NUMBER_2","COMPLEMENT_PRODUCT_ID","SHIPPING_SIZE_ID","ADV_ALLOW_SHIPPING","ADV_ALLOW_PICKUP","ADV_PICKUP_PHONE_NUMBER","ADV_PICKUP_ZIP","ADV_PICKUP_COUNTRY_ID","IS_SELLER_VAT_EXEMPTED", "VAT_COUNTRY_ID","VAT_DISCLAIMER","SELLER_NEGO_PRICE","IS_CBV_APPLICABLE" FROM "BABEL_BI"."ITEM" "ITEM" WHERE ( trunc(CHANGE_DATE)>=TRUNC(sysdate-2) OR (trunc(CREATION_DATE)>=TRUNC(sysdate-2)) AND trunc(CREATION_DATE)<TRUNC(sysdate); avec : -------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | -------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 438K| 461M| | 20430 (2)| 00:04:06 | |* 1 | TABLE ACCESS BY INDEX ROWID | ITEM | 438K| 461M| | 20430 (2)| 00:04:06 | | 2 | BITMAP CONVERSION TO ROWIDS | | | | | | | | 3 | BITMAP OR | | | | | | | | 4 | BITMAP CONVERSION FROM ROWIDS| | | | | | | | 5 | SORT ORDER BY | | | | 7000K| | | |* 6 | INDEX RANGE SCAN | ITM_IX_BI_3 | 18M| | | 78 (2)| 00:00:01 | | 7 | BITMAP CONVERSION FROM ROWIDS| | | | | | | | 8 | SORT ORDER BY | | | | 6872K| | | |* 9 | INDEX RANGE SCAN | ITM_IX_BI_4 | 18M| | | 59 (0)| 00:00:01 | -------------------------------------------------------------------------------------------------------- Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 101925 consistent gets 0 physical reads 0 redo size 66708511 bytes sent via SQL*Net to client 163890 bytes received via SQL*Net from client 14852 SQL*Net roundtrips to/from client 2 sorts (memory) 0 sorts (disk) 222756 rows processed On pourrait même envisager : WHERE ( trunc(CHANGE_DATE)>=TRUNC(sysdate-2) AND trunc(CREATION_DATE)<TRUNC(sysdate)) OR trunc(CREATION_DATE) in (TRUNC(sysdate-2), TRUNC(sysdate-1) ) Qu'en penses-tu ? |
| Commentaire de Patrick Pereira [ 14/avr./08 17:56 ] |
|
Pb sur item réglé par la création des indexes : ITM_IX_BI_1(trunc(creation_date)); ITM_IX_BI_2(trunc(change_date),trunc(creation_date)); |
[BIN-583] [CBV] : Migration d'un rapport perso sour BI Création: 25/mai/09 09:07 Mise à jour: 11/juin/09 09:16 Résolue: 28/mai/09 10:27 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | CRM |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Thomas Beylot | Attribution: | Dalila Belkebir |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Hello, Dans le cadre de la reprise par Julien du chantier CBV (et donc de son suivi mensuel) il faudrait que nous ayons accès à un rapport développé avec Pkr il y a un an de cela. Or ce rapport n'est accessible que dans le dossier perso de Pkr, qui lui même ne nous est pas accessible. Pouvons nous migrer les dit rapports sous le perso de Julien ? Les noms des rapports, dans CBV, dans le dossier pkr: - cbv agglo 0-4.99, 5-14.99 et 15+. merci thomas |
| Commentaires |
| Commentaire de Dalila Belkebir [ 27/mai/09 09:56 ] |
|
Bonjour, En raison d'une opération de maintenance, la prod BI n'est pas disponible aujourd'hui. Dès son rétablissement je me charge de la demande. Cdlt, Dalila. |
| Commentaire de Dalila Belkebir [ 28/mai/09 10:27 ] |
|
Thomas, Je viens de vérifier et il se trouve que le répertoire de PKR existe toujours dans les favoris du User UR Marketing. Donc tu peux en faire une copie ou les exploiter directement : tu y as accès :-) => aucune action de notre part n'est nécessaire. Cdlt, Dalila. |
| Commentaire de Agathe Remy [ 10/juin/09 17:56 ] |
|
Bonsoir Thomas, S'il te plait, peux-tu confirmer que vous avez accès aux rapports demandés? Merci. Agathe |
| Commentaire de Thomas Beylot [ 11/juin/09 09:09 ] |
|
Hello je confirme ! merci beaucoup thomas |
[EXP-4647] [BI UK] Impact TX-D bis (fonction toeuro et toeuro2) sur le reporting BI sur TERRA Création: 17/déc./08 14:56 Mise à jour: 13/janv./09 14:53 Résolue: 13/janv./09 12:44 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Maintenance |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Nouvelle fonctionnalité | Priorité: | Bloquant |
| Rapporteur: | Dalila Belkebir | Attribution: | Patrick Pereira |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Suite au projet BI UK, les fonctions toEuro et toEuro2 vont être migrées en toDfltCurrcyFullPrec et toDfltCurrcy Il faut donc vérifier que cela n'impacte pas le reporting BI sur TERRA. Cette modification interviendra le 12/01/2009 lors de la livraison des impacts UK sur les plateformes FR & ES (TXD bis). Merci de vous assurer que les impacts TXD bis soient bien pris en compte sur le reporting le 13/01/09 toEuro et toEuro2 deviendront : FUNCTION toDfltCurrcyFullPrec(amount NUMBER, currencyId NUMBER) RETURN NUMBER deterministic IS BEGIN IF (currencyId = CURRENCY_FRF) THEN RETURN amount / EURO_RATE; ELSE RETURN amount; END IF; END; FUNCTION toDfltCurrcy(amount NUMBER, currencyId NUMBER) RETURN NUMBER deterministic IS BEGIN RETURN ROUND(toDfltCurrcyFullPrec(amount, currencyId), 2); END; Merci. Dalila. |
| Commentaires |
| Commentaire de Patrick Pereira [ 13/janv./09 12:44 ] |
| C'est bon. |
| Commentaire de Dalila Belkebir [ 13/janv./09 14:53 ] |
|
Bonjour Patrick, Peux-tu détailler les actions menées pour vérifier la présence ou non d'impacts du changement des fonctions de conversion des devises ? Les fonction to-euro et to_euro2 ne sont-elles pas appelées à disparaitre d'ici peu ? Merci de ton retour, dalila. |
[BIN-426] [Spain] : Le champ "state-id" n'est pas disponible dans BI Création: 04/avr./08 18:32 Mise à jour: 14/mai/08 15:33 Résolue: 23/avr./08 17:31 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Charles Decaux | Attribution: | Samir Beghdadi |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
screenshot-1.jpg
|
| Pays: |
ESP - Espagne
|
| Description |
|
Hello J'ai besoin de connaître la région de certains de mes acheteurs en utilisant BI. Or dans l'ensemble "shipping address" je n'ai pas à ma disposition la région. Serait-il possible de l'ajouter ? Merci |
| Commentaires |
| Commentaire de Agathe Remy [ 23/avr./08 17:31 ] |
|
Charles, Peux-tu valider l'ajout des objets suivants : SPAIN - ITEM : Buyer account/Shipping address/Shipping address state Id Buyer account/Shipping address/Shipping address state name Seller account/Payment address/Payment address state Id Seller account/Payment address/Payment address state name Seller account/Meeting address/Meeting address state Id Seller account/Meeting address/Meeting address state name SPAIN - PURCHASE : User account/Shipping address/Shipping address state Id User account/Shipping address/Shipping address state name SPAIN - ADVERT : User account/Payement address/Payment address state Id User account/Payement address/Payment address state name User account/Meeting address/Meeting address state Id User account/Meeting address/Meeting address state name SPAIN - USER_ACCOUNT Shipping address/Shipping address state Id Shipping address/Shipping address state name Payment address/Payment address state Id Payment address/Payment address state name Meeting address/Meeting address state Id Meeting address/Meeting address state name Merci. Agathe |
| Commentaire de Charles Decaux [ 25/avr./08 10:37 ] |
|
J'ai fait un test dans Purchase. User account --> Shipping address --> pas de state id je ne le trouve pas, voir screen shot merci |
| Commentaire de Samir Beghdadi [ 25/avr./08 15:52 ] |
|
Charles, Oui c'est normal l'univers PURCHASE n'été pas encore en production. Maintenant tu peux tester les trois univers (ITEM, PURCHASE et USER ACCOUNT). Merci Samir |
| Commentaire de Agathe Remy [ 14/mai/08 15:23 ] |
|
Bonjour Charles, Petite relance pour valider cet ajout?! Merci:-) Agathe |
| Commentaire de Charles Decaux [ 14/mai/08 15:32 ] |
| je viens de tester, c'est impeccable, merci !! |
[BIN-263] ajout des champs grant_login et user compensation right code sur BI Création: 10/janv./07 10:47 Mise à jour: 14/sept./07 17:34 Résolue: 10/janv./07 13:24 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Alexandra Viravaud | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Salut Agathe, il faudrait ajouter les champs grant_login et user compensation right code sur BI pour la relance auprès des personnes non abonnées à l'automatisation. Envoi du mail via MM le 29 janvier Merci Alex |
| Commentaires |
| Commentaire de Agathe Remy [ 10/janv./07 10:50 ] |
|
Je ne pense pas que ce soit pour le mail de relance auprès
des personnes non abonnées à l'automatisation, mais plutôt le mail aux
détenteurs de PMV positifs?! Agathe |
| Commentaire de Agathe Remy [ 10/janv./07 10:53 ] |
|
Au fait pour l'envoi, es-tu sure que ce n'est pas le 18/01? Merci:-) |
| Commentaire de Alexandra Viravaud [ 10/janv./07 10:59 ] |
| oui tu as raison. j'ai fait un mix entre les 2 mails :( |
| Commentaire de Alexandra Viravaud [ 10/janv./07 11:22 ] |
| Juste pour info, j'ai ajouté la condition de validation auto (buyer reliability) est -1 ou -2 sur le rapport. |
| Commentaire de Agathe Remy [ 10/janv./07 13:24 ] |
|
C'est fait : tu trouveras les objets User grant login et
User compensation rigth code dans la classe User Account de l'univers
France - User Account. Pour info : compte non bloqué : User grant login = 1 compensation non bloquée : User compensation rigth code != 20 |
| Commentaire de Alexandra Viravaud [ 10/janv./07 17:55 ] |
| Agathe, je ne vois pas les dits champs sur l'univers users. Tu peux m'éclairer ? |
| Commentaire de Agathe Remy [ 10/janv./07 18:13 ] |
|
C'est corrigé. Tu devrais pouvoir les trouver à présent. Agathe |
| Commentaire de Alexandra Viravaud [ 10/janv./07 18:28 ] |
| ca marche. merci. |
[BIN-303] [Wish] : Demande de mise à disposition des données de suivi des souhaits dans BI Création: 08/mars/07 15:27 Mise à jour: 01/oct./08 10:34 Echéance: 30/sept./08 00:00 Résolue: 01/oct./08 10:34 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Thomas Beylot | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Ce serait bien d'ajouter les éléments nous permettant de
suivre la fonction "souhait" à BI. En fait la demande vient du fait
qu'un des objo de la nouvelle FP est de booster le souhait. Donc il faut
qu'on puisse le suivre :-) merci !! thomas |
| Commentaires |
| Commentaire de Agathe Remy [ 02/janv./08 11:32 ] |
|
Thomas, Cette demande a été planifiée pour Q3 2008. Agathe |
[BIN-142] ajout de tracking id dans les rapports BI "incitation achat" et "incitation vente" Création: 24/août/06 19:06 Mise à jour: 14/sept./07 17:19 Résolue: 02/oct./06 12:43 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Alexandra Viravaud | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | 2 heures | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | 2 heures | ||
| Description |
|
Mohamed, comme prévu voici tous les codes de tracking qui doivent être présents dans nos nouveaux rapports BI incentive achat et incentive vente. Incentive achat : 727140 727141 727142 727143 1041740 1041741 1366040 Incentive vente : 727144 727145 1396045 1402140 1396048 1464040 Peux-tu me prévenir quand c'est prêt? Merci beaucoup. Alexandra |
| Commentaires |
| Commentaire de Mohamed Ezzouak [ 25/août/06 18:28 ] |
|
Les conditions sur les tracking ont été modifiées pour inclure les nouveaux tracking automatisation. Les univers Purchase et Advert ont été modifiés en conséquence. Le rapport personnal d'Alexandra a été modifié également pour prendre en considération ces tracking. NB : Il manquait dans la liste des tracking pour les mails incitation à l'achat le numéro : 1111741 Il a été également ajouté. |
| Commentaire de Alexandra Viravaud [ 02/oct./06 12:38 ] |
| demande faite. fermer le jira |
[BIN-514] [Finance] : Données manquantes dans le rapport BI "Wallet by user" Création: 13/nov./08 09:51 Mise à jour: 26/nov./08 11:38 Résolue: 13/nov./08 18:42 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Finance |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Bloquant |
| Rapporteur: | Samira Remila | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Dalila, Agathe, Nous avons sortis le rapport BI "Wallet by user" mais nous constatons qu'il n'est pas complet car il manque le détail des PMV non actifs. Nous aurions besoins de ces données pour pouvoir avancer dans l'analyse du seller crédit. Montant du Wallet by user ( BI ) au 1er novembre 2008 est de : 5 614 269,61¿ Montant du Wallet Report ( TITAN ) au 1er novembre 2008 est de : 7 281 225,86 ¿ Soit un écart de 1 666 956,25 ¿ Si vous avez des questions n'hésitez surtout pas. Pourrais vous nous tenir au courant du délai qu'ils vous faudraient pour rajouter les PMV manquants ? Merci par avance. Samira |
| Commentaires |
| Commentaire de Agathe Remy [ 13/nov./08 11:36 ] |
|
Bonjour Samira, Pour obtenir les PMV manquants, il te suffit de rafraichir la liste de valeur dans l'invite et de sélectionner les nouveaux statuts du PMV. Cordialement, Agathe |
[META-TACHE] Modification des tracking sites-under + tracking e-mails questions
(APP-26706)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Affiliation |
| Affecte la/les version(s): | 55.0.2 .1 |
| Version(s) corrigée(s): | 56.0.2 |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | Mathilde Caby | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM archivés: | Tracking affiliation |
| Description |
|
Bonjour, Nous avons besoin de modifier le rapport BI: France-> Affiliation-> Partner - Affiliation purchase checking En effet nous rémunérons actuellement les affiliés sur le volume d'affaire. Hors cette rémunération changera le 2 novembre prochain. Nous rémunérerons à partir de cette date les affiliés au pourcentage de la commission hors taxe et hors frais de port. Nous aurons donc désormais cette commission qui remontera chez les plateformes. Actuellement le frapport BI : France-> Affiliation-> Partner - Affiliation purchase checking nous remonte le montant du volume d'affaire par panier avec la reference panier et la date de ce panier. Nous aimerions qu'a partir du 2/10/2009 ce rapport nous remonte le montant de la commission hors taxe, hors frais de port par panier avec la référence panier et la date de celui-ci. Il faut donc juste remplacer le montant du volume d'affaire par panier par la commission hors frais de port, hors taxe du panier. Pour information: ce rapport nous est envoyé automatiquement tous les lundis matin pour les 2 plateformes suivantes: Zanox et Affilinet(=cibleclickx) Et nous le générons manuellement tous les lundis pour les 2 plateformes : Effiliation et CJ. Nous générons manuellement le rapport pour la validation des ventes du mois précédent pour les 4 plateformes en début de mois (au 10 du mois suivants maximum). C'est pourquoi, nous aurons encore besoin de l'ancienne version du rapport jusqu'au 10/11/2009. Je suis à votre disposition pour toutes questions Merci Mathilde |
| Commentaires |
| Commentaire de Fabrice Feugas [ 14/oct./09 15:34 ] |
| Présentation du projet dans cette page : http://pricewiki.lan/Wiki.jsp?page=Tracking%20afiliation%20%28Sites%20Under%20%2B%20emails%20question%29 |
| Commentaire de Cyril Tanneau [ 20/oct./09 15:00 ] |
|
Salut Mathilde, tu précises dans le jira que vous aimeriez que le rapport remonte "la commission hors taxe, hors frais de port par panier". S'agit'il de la commission autorisée ou capturée? Merci, Cyril |
| Commentaire de Mathilde Caby [ 20/oct./09 16:42 ] |
|
Hello Cyril, Nous voulons la commission hors taxe et hors frais de port capturée stp |
| Commentaire de Cyril Tanneau [ 20/oct./09 16:51 ] |
| OK, merci Mathilde |
| Commentaire de Dalila Belkebir [ 02/nov./09 15:56 ] |
|
Mathilde, Suite à notre point de ce matin, je te propose de rester sur le capturé avec les indicateurs déjà en place (OK, ATTENDRE etc ...). Par contre, je te propose de changer le nom des rapports à l'instar de ce qui existe sur PURCHASE/PARTNERS selon : Partner - Affiliation purchase checking devient Affiliation sur volume d'affaires par groupe de tracking du panier le nouveau rapport s'appellera Affiliation sur commission nette hors FP par groupe de tracking du panier De cette manière nous pourrons garder les 2 types de rapport et les exploiter si besoin(d'historique ou bien de nouveaux partanires sur ce modèle de volume d'affaires). Souhaites-tu garder le nom des rapports en anglais ? |
| Commentaire de Mathilde Caby [ 02/nov./09 15:59 ] |
|
Dalila, C'est parfait comme proposé en français ci-dessus. Merci Mathilde |
| Commentaire de Dalila Belkebir [ 02/nov./09 19:25 ] |
|
Mathilde, j'ai mis en production - le nouveau rapport : Affiliation sur commission nette hors FP par groupe de tracking du panier - le renomage du rapport existant Partner - Affiliation purchase checking en Affiliation sur volume d'affaires par groupe de tracking du panier Tu les trouveras dans publics folders/ France Affiliation. Je l'ai également mis en place le nouveau rapport pour UK et ES. J'ai exécuté le rapport en France pour Zanox et Cibleclickx que tu trouveras dans les instances exécutées. Merci de tes retours pour validation du JIRA. Cdlt, Dalila. Cordialement, Dalila. |
| Commentaire de Christophe Garcia [ 03/nov./09 11:09 ] |
| MDPLVC |
| Commentaire de Mathilde Caby [ 03/nov./09 16:32 ] |
|
J'ai fait la vérification des deux rapports. Ils sont tous les deux corrects. Merci pour cette mise en place Mathilde |
[BIN-167] BI Finance : éclatement du seller bonus en seller bonus et seller malus Création: 10/oct./06 16:51 Mise à jour: 14/sept./07 17:21 Résolue: 10/oct./06 17:57 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Executive |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Critique |
| Rapporteur: | Agathe Remy | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | 2 heures | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | 2 heures | ||
| Pays: |
FRA - France
|
| Description |
|
Une demande complémentaire visant à finaliser le lot 1 du BI Finance : Les rapports sur les claims intègrent à présent les « seller bonus » ce qui n'étaient pas le cas des rapports sous Titan. Les « seller bonus » peuvent être soit positifs soit négatifs (par exemple cas d'un vendeur n'ayant pas suffisamment affranchi son colis). Or au moment des compensations seuls les seller bonus positifs (somme dues par PM à un vendeur) sont repris ; les seller bonus négatifs ne sont quant à eux jamais imputés sur les comptes des vendeurs. Sur le plan financier, on a donc un souci dans la mesure où on constate un produit mais qu'on ne l'encaisse jamais ; il faut donc absolument qu'on arrête de comptabiliser ces seller bonus positifs tant et aussi longtemps que le mécanisme des compensations ne les prendra pas en compte. Cela nécessite quelques aménagements des rapports portant sur les claims : il faut éclater les colonnes « seller bonus » en deux colonnes distincts : « seller bonus » et « seller malus ». |
| Commentaires |
| Commentaire de Agathe Remy [ 10/oct./06 17:11 ] |
|
Philippe, Si je comprends bien ta demande, tu veux que l'on sépare les montants positifs et négatifs du champ seller bonus dans tous les onglets où il apparaît. Peux-tu me le confirmer ? Merci. Agathe |
| Commentaire de Philippe Favrot [ 10/oct./06 17:20 ] |
|
oui Philippe |
| Commentaire de Agathe Remy [ 10/oct./06 17:57 ] |
|
Le rapport Claim status by month avec la distinction seller bonus/seller malus a été livré en Production. Cordialement, Agathe |
[BIN-240] extraction des personnes ayant fait leur 1ère vente effective sur BI Création: 07/déc./06 16:45 Mise à jour: 14/sept./07 17:32 Echéance: 22/déc./06 00:00 Résolue: 18/déc./06 16:05 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Alexandra Viravaud | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | 2 heures | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | 2 heures | ||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Description |
|
Hello Agathe, Nous souhaitons prochainement faire un partir un test sur le coupon vendeur. Rappel de l'objectif de ce mail : Proposer aux acheteurs qui n'ont pas d'inventaire de découvrir la vente sur PM. On leur attribue un bon d'achat s'ils réalisent une 1ère vente clôturée sur le site. Le test se déroule donc en plusieurs étapes : 1/ l'acheteur recoit un mail "devenez vendeur et nous vous offrons 3¿ sur un prochain achat" = message 1 2/ le mec dépose des annonces et fait sa 1ère vente 3/ il recoit par email le bon d'achat de 3¿ = message 2 Pb : Il reste encore du boulot pour que ce chantier soit prêt (3 créas à faire + validation du coupon vendeur côté technique) -> le message ne pourra pas partir à temps pour que nous collections les résultats du test sur EMV. Il faudrait donc que le message parte de chez MM. Peut-on faire l'extraction de la population de départ sur BI puis voir sur cette population cb de personnes font une 1ère vente effective ? Dans ce cas il faudrait prévoir de faire chaque semaine l'extract des personnes qui ont fait leur 1ère vente effective pour leur envoyer le bon de réduction. Peux-tu me dire si c'est faisable ? L'idéal serait de faire une réunion sur ce projet. Demain ou lundi, tu serais libre ? Alexandra |
| Commentaires |
| Commentaire de Agathe Remy [ 11/déc./06 17:40 ] |
|
Alex, Petit récap du point fait avec OZA ce matin : - Pour le 1er envoi du test avec EMV, vous n'avez pas besoin de nous. Il faut en revanche, une fois le mail de test envoyé, nous prévenir afin que nous récupérions les emails des personnes ayant reçu ce mail via Campaign Commander. - Chaque fin de semaine (jeudi, vendredi?), faire une extraction des personnes ayant reçu le mail de test et ayant réalisées leur premier vente effective : peux-tu nous définir les champs nécessaires (email, user id, pseudo, ...) et les critères de sélection (ayant reçu le mail test et ayant effectué leur première vente effective dans la semaine écoulée, ...) - Voir avec 1000Mercis comment ils vont pouvoir envoyer les emails d'attribution du coupon et quel format de fichier ils veulent (fichier texte avec séparateur ";", fichier XML, etc...) Merci:-) Agathe |
[BIN-133] Reporting BI sur les mails automatiques "parrainage" : rapport non parrains et rapport filleuls Création: 11/août/06 15:03 Mise à jour: 14/sept./07 17:18 Résolue: 09/oct./06 12:52 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Alexandra Viravaud | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Salut Agathe, On souhaiterait mettre en place de nouveaux rapports BI sur tous les mails automatiques "parrainage". Il s'agit de faire une même requête sur BI que sur EMV en regardant la population qui a recu le message de parrainage correspondant (M9 ou M11 dans le cas présent). 1/ Rapport non parrains Rapport sur la population qui a recu M9-nonparrain-AouV Population : les non parrains ayant déjà réalisé au moins un achat non annulé à 100% et/ou une vente) Règle d'envoi : 2 jours après son dernier achat ou sa dernière vente puis tous les 4 mois Sur EMV : (where member.BRAND_NAME equals "www" and where member.TOTAL_CHILDREN_COUNT = 0 and where member.PURCHASE_VALID_COUNT = 0 and where member.SALE_CONFIRMATION_COUNT = 1 and where member.IS_NOT_PARENT_SUBSCRIBER = 1 or where member.BRAND_NAME equals "www" and where member.TOTAL_CHILDREN_COUNT = 0 and where member.PURCHASE_VALID_COUNT = 1 and where member.PURCHASE_CANCEL_PERCENT < 100 and where member.SALE_CONFIRMATION_COUNT = 0 and where member.ADVERT_COUNT = 0 and where member.IS_NOT_PARENT_SUBSCRIBER = 1 ) and ( NOT (who received message 245130 ) or NOT (who were sent message 245145 ) or NOT (who were sent message 245146 )) Nb de parrains total Dt nb de parrains A Dt nb de parrains V Dt nb de parrains A et V Dt nb de parrains NANV Ratio parrains/A ou V Nb de filleuls dont comptes ouverts dont comptes contact Nb de filleuls actifs Dont nouveaux acheteurs Dont nouveaux vendeurs Dont acheteurs-vendeurs Nb de coupons filleul utilisés Nb de coupons parrain utilisés Nb de paniers (avec / sans coupon): Valeur articles Commission HT TVA sur commission CA Périodicité du rapport souhaité : mensuelle 2/ Rapport filleul Rapport sur la population qui a recu M11-filleuls-NA Population : filleuls non acheteurs (uniquement depuis le 6 juillet 2004) Règle d'envoi : 15 jours après être devenu filleul (une fois) Sur EMV : M11 relance filleul fil de l'eau ( hors stock initial mai 06) Condition where member.PARENT_LOGIN is not empty and where member.BRAND_NAME equals "www" and where member.EMVDOUBLON is empty and where member.PURCHASE_VALID_COUNT = 0 and where member.RESENT_CHILD = 0 and where member.ACCOUNT_CREATION_DATE is after 07/06/2004 and where member.USR_TYPE_IDENTIFIER equals "contact" and NOT (who were sent message 1 of series 8913 ) M11 relance filleuls_rattrapage2_DEF Condition where member.PARENT_LOGIN is not empty and where member.BRAND_NAME equals "www" and where member.EMVDOUBLON is empty and where member.PURCHASE_VALID_COUNT = 0 and where member.RESENT_CHILD = 0 and where member.USR_TYPE_IDENTIFIER equals "equals" and where member.ACCOUNT_CREATION_DATE is after 05/20/2006 03:40 and where member.ACCOUNT_CREATION_DATE is before or on 05/30/2006 00:00 Nb total de filleuls* depuis le début (*personnes ayant le tracking filleul) Nb total de nouveaux comptes filleuls par mois Nb de filleuls NA Nb de comptes ouverts Nb de comptes contacts Nb de filleuls actifs depuis le début dont A dont V dont A-V Nb de filleuls actifs par mois Nb de paniers (avec / sans coupon): Valeur articles Commission HT TVA sur commission CA Abonnés à au moins une des newsletter (generale, High Tech, Maison & Loisirs) Abonnés aux offres partenaires Abonnés à l'automatisation Périodicité du rapport souhaité : mensuelle On s'en reparle de vive voix. Merci Alexandra |
| Commentaires |
| Commentaire de Agathe Remy [ 09/oct./06 12:52 ] |
|
Vu avec OSA : le rapport a été livré le 06/10. Agathe |
| Commentaire de Mohamed Ezzouak [ 10/oct./06 18:51 ] |
|
Un rapport sur le parrainage a été produit. Il est dans le répertoire personnel de Alexandra. Le tracking au niveau de la newsletter Parrainage ne pouvant être personnalisé nous ne pouvons obtenir les informations relatives aux nouveaux parrains suites à l'envoi du mail. Pour l'instant nous produisons des indicateurs synthétiques sur le nombre de parrains/filleuls. |
[BIN-540] [BACK-OFFICE] : Créér accès limité à BI dans un dossier donné Création: 07/janv./09 14:01 Mise à jour: 05/févr./09 18:20 Résolue: 05/févr./09 17:59 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | BackOffice |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Cedric Favero | Attribution: | Dalila Belkebir |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Je voudrais mettre à disposition de mon équipe , dans un
dossier donné et avec accès limité, quelques requetes prédéfinies que
j'aurai créées spécialement. Ceci pour pallier à certaines choses que le BO ne sait pas faire ou fait mal.. Ou encore pour acceder à des informations archivées et donc plus visibles en BO (ex: evenements) ex: recherche par IP sans limitation de date recherche par adresse de livraison recherche de compte par nom & prenom ... Faire donc en sorte d'arriver dans un dossier donné, sans autre possibilité que de lancer les requetes présentes. login/mdp proposés: bo / babelstore ( les memes que Back-Office) Merci d'avance. |
| Commentaires |
| Commentaire de Dalila Belkebir [ 07/janv./09 19:14 ] |
|
Bonjour Cédric, Peux -tu me donner plus de précisions STP ? Veux que ces personnes puissent accéder au répertoire back office existant dans public ou en tout cas à certains rapports "public" ? Veux-tu uniquement leur soumettre des rapports persos que tu auras créés ? Je te propose de : - créer un autre User UV Back Office avec un mot de passe spécifique. - créer un répertoire PUBLIC / BACK OFFICE / Basics - créer un répertoire PUBLIC / BACK OFFICE / Specific Ce nouveau User ne verra que le répertoire public / BACK OFFICE / Basics Le user UV BACK OFFICE aura accès à PUBLIC / BACK OFFICE / Specifics et PUBLIC / BACK OFFICE / Basics Il te suffira de nous dire quels rapports tu souhaites mettre dans Basics s'il s'agit de rapports publics ou nous dire quels rapports perso tu souhaites envoyer sur la boite de réception du user UV BACK OFFICE Proposition non contractuelle susceptible de changer mais l'idée est là :-) Dalila. |
| Commentaire de Cedric Favero [ 08/janv./09 09:09 ] |
|
Pour les modalités, on voit ensemble mais c'est jute donner accès limité à un dossier prédéfini. C'est moi ensuite qui y mets les rapports et requetes que je veux mettre à disposition. |
| Commentaire de Dalila Belkebir [ 08/janv./09 12:07 ] |
|
Cédric, Je vais travailler dessus le 13/01 pour une mise en production le 15/01. On se voit donc mardi prochain sur les modalités : à 14h ? Dalila. |
| Commentaire de Cedric Favero [ 08/janv./09 12:33 ] |
|
çà me va (tu m'envoies l'invite?) mais vraiment au plus simple, juste créer un accès limité un dossier unique. Ensuite dedans je pourrai faire des sous-dossiers FR/ES/UK et mettre ce que je veux dedans.. PUBLIC / BACK OFFICE / Basics me va Merci. |
| Commentaire de Dalila Belkebir [ 29/janv./09 12:23 ] |
|
Bonjour Cédric, Juste un petite question non abordée jusque là : souhaites tu autoriser les users à créer des rapports dans leur répertoire perso "mes favoris" ? Ou bien ne doivent-ils faire que de la visualisation ? Merci . Dalila. |
| Commentaire de Cedric Favero [ 29/janv./09 13:41 ] |
|
Compliqué si on le fait en 2 temps? D'abord uniquement de la visualisation et du lancement de requetes prédéfinies. Puis le jour om on veut le faire , on active cette possibilité? Car dans un premier temps , ceux à qui je laisserais cette lattitude useraient plutot du login ur_backoffice. Merci. |
| Commentaire de Dalila Belkebir [ 30/janv./09 16:41 ] |
|
OK je mets juste des droits de visu dans un premier temps. Ensuite, on avisera. Pour info, MEP prévue mardi midi. dalila. |
| Commentaire de Dalila Belkebir [ 05/févr./09 17:59 ] |
|
Cédric, Les nouveaux éléments sont-ils OK pour toi en prod BI ? - le nouveau répertoire Bo Working - le nouvel utilisateur UV Backoffice merci de ton retour pour clôture du JIRA ? Cdlt, Dalila. |
| Commentaire de Cedric Favero [ 05/févr./09 18:06 ] |
|
Oui c'est tout bon et un tres grand progres pour nous. Merci beaucoup. Petite question subsidiaire: Au lieu d'avoir les classiques liens: Historique | Planifier | Modifier | Propriétés Ne peut on avoir juste un lien "actualiser" ou "lancer" ? Merci. |
| Commentaire de Dalila Belkebir [ 05/févr./09 18:20 ] |
|
Cédric, Je ne pense pas que nous puissions modifier le menu de l'applicatif mais je vais quand même regarder. Sinon, je te propose d'en faire la suggestion à l'éditeur : Business Object ;-) Merci de ton retour (et bonne vacances !). A ta disposition pour vous rendre le BI plus simple. Cdlt, Dalila. |
[EXP-4581] [Reporting BI] : Pb de performance des requêtes sur TA_USR_EVENT Création: 21/oct./08 12:03 Mise à jour: 25/mars/09 18:15 Résolue: 25/mars/09 18:15 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Bloquant |
| Rapporteur: | Agathe Remy | Attribution: | Patrick Pereira |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
requetes_TA_USR_EVENT.sql
|
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Afin de permettre l'archivage des données de USR_EVENT sur la base OLTP, nous avons rapatrié toutes des données dans notre DataWareHouse (schéma DWH, table TA_USR_EVENT) et nous avons développé un rapport qui permet au BackOffice d'accéder aux évènements d'un pseudo donné. Nous avons créé cette table avec les mêmes informations de partitionnement que celles définies dans la base OLTP, à savoir par USER_ACCOUNT_ID. Ce partitionnement nous permet d'avoir des temps de réponse très satisfaisant pour le rapport BackOffice. En revanche, nous avons de nouveaux besoins de reporting du type "nombre d'évènements d'abonnement à un type d'abonnement entre telle et telle date" ou "liste des descriptions (qui contiennet l'url) des évènements widget". Ces requêtes ne filtrent donc pas le USER_ACCOUNT_ID et leur temps de réponse n'est pas satisfaisant (plus de 5 minutes). Nous avons essayé de créer un index global sur le type d'évènement (USE_TYPE_CODE), mais nos temps de réponse ne sont toujours pas satisfaisants. S'il vous plait, pouvez-nous nous aider à optimiser ces requêtes? Merci. Agathe |
| Commentaires |
| Commentaire de Agathe Remy [ 21/oct./08 12:14 ] |
|
Bonjour, Vous trouverez ci-joint 2 requêtes types dont les temps d'exécution ne sont pas satisfaisants. A votre dispo si vous avez des question. Agathe |
| Commentaire de Ayoub Benseghir [ 28/oct./08 17:06 ] |
|
Bonjour, Pour la première requête: un hint /*+ no_parallel(TA_USR_EVENT)*/ fait passer le temps d'exécution à 10sec. |
| Commentaire de Ayoub Benseghir [ 29/oct./08 12:18 ] |
| Rectification: le no_parallel ne regle pas le problème. |
| Commentaire de Agathe Remy [ 05/janv./09 11:19 ] |
|
Bonjour, Suite à la replanification du projet BI Abonnement, la priorité de ce JIRA devient très forte, puisque bloquante pour la livraison du projet. De plus, nous commençons à avoir des remontées de mécontentement également au niveau du BackOffice. Voici un exemple de requêtes que nos utilisateurs n'arrivent pas à exécuter en raison de leur trop long temps d'exécution : SELECT DTM.TD_USER_ACCOUNT.LOGIN FROM DTM.TD_USER_ACCOUNT, TD_USE_TYPE_CODE, TA_USR_EVENT WHERE ( TA_USR_EVENT.USE_TYPE_CODE=TD_USE_TYPE_CODE.USE_TYPE_CODE ) AND ( TA_USR_EVENT.USER_ACCOUNT_ID=DTM.TD_USER_ACCOUNT.USER_ACCOUNT_ID ) AND ( TD_USE_TYPE_CODE.LABEL = 'Compensation explicite' AND TA_USR_EVENT.CREATION_DATE > '01-09-2008 00:00:00' ) ; Agathe |
| Commentaire de Agathe Remy [ 25/mars/09 18:15 ] |
|
Suite aux investigations de Patrick, de nombreuses
optimisations sur USR_EVENT ont été mises en place dans la cadre du
projet BI Abonnement qui permettent des temps de réponses tout à fait
acceptables par les utilisateurs. Je considère donc ce JIRA comme résolu. Agathe |
Installation Business Objects Production
(BIN-15)
|
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | Sébastien Tournay | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | 0 minutes | ||
| Temps consacré: | 1 heure, 10 minutes | ||
| Estimation originale: | 1 heure | ||
| Description |
|
Faire la demande à JMH (MAI) pour demander la création du
domaine bi.priceminister.com. On utilise la même VIP que celle de
bo.priceminister.com et donc les 2 RIP. Mettre en place la conf Apache et mod_jk pour attaquer le serveur applicatif BO sur TELLUS (après validation de la préocédure en intégration) |
| Commentaires |
| Commentaire de Ranto Andriambololona [ 09/déc./05 15:24 ] |
|
Je viens de soumettre dans l'extranet JET la demande pour le domaine bi.priceminister.com et l'ajout des RIP et VIPS Pour la mise ne place de la conf apache et mod_jk, on le fera le jour où BO sera installé completement et opérationnel sur TELLUS |
| Commentaire de Ranto Andriambololona [ 16/déc./05 12:40 ] |
|
C'est fait et accessible sur : http://bi.priceminister.com/businessobjects/enterprise11/ J'ai aussi ajouté une sécurité pour que seul notre IP (Villette) puisse accéder à bi.procmeinister.com |
[BIN-118] pas de données sur le rapport BI "new buyers after mailing" avril à juin 2006 Création: 10/juil./06 14:23 Mise à jour: 14/sept./07 17:17 Résolue: 10/juil./06 14:36 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Alexandra Viravaud | Attribution: | Agathe Remy |
| Résolution: | Invalid | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Salut, en rafrachissant le rapport existant, je n'ai pas de données sur les new buyers after mailing sur la période avril à juin 2006. Est-ce que tu peux voir ca? Merci Alexandra |
| Commentaires |
| Commentaire de Agathe Remy [ 10/juil./06 14:36 ] |
|
Bonjour, Tu trouveras le rapport "New buyers after mailing 2006-04/2006-06" rafraichi avec des données (?!) dans le répertoire Favoris/Alexandra. Te connectes-tu bien à BusinessObjects à l'adresse http://bi.priceminister.com ??? J'ai peur que tu sois connectée au site de développement (http://bi.pm.lan)... Agathe |
| Commentaire de Alexandra Viravaud [ 10/juil./06 15:54 ] |
| j'étais en effet sur une mauvaise adresse :( |
Affiliation Programme Vendeur :: Metatache
(APP-15282)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Affiliation |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 17.0.0 |
| Type: | Sous-tâche | Priorité: | Mineur |
| Rapporteur: | Richard Dubois | Attribution: | Romain Czornomaz |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM: | *** RESERVE *** |
| Commentaires |
| Commentaire de Romain Czornomaz [ 23/févr./07 14:41 ] |
|
Comme convenu ce matin lors de la réunion pour la mise en
place du suivi des fraudeurs dans le cadre de l'affiliation vendeurs, On doit fournir un rapport permettant de suivre les éléments suivants: - Date de création ou date de publication ( Ghislain doit se renseigner pour savoir quelle date sera utiisée pour les tags affiliations) - Identifiant de l'annonce - Statut de l'annonce - Type de produit - Prix de vente du produit - Login du compte vendeur - Email du compte vendeur - Mot de passe du compte vendeur - Adresse IP du compte vendeur Romain |
| Commentaire de Romain Czornomaz [ 27/juil./07 15:58 ] |
|
Bonjour, Les rapports affiliation vendeur sont déployés sur la plateforme BI. Romain |
| Commentaire de Ghislain Gridel [ 27/juil./07 17:26 ] |
| ok. merci. |
[APP-15314] BI : Ajout d'un champ CHANGE_DATE dans USR_TRACKING Création: 26/févr./07 15:30 Mise à jour: 25/juin/07 18:49 Résolue: 20/avr./07 15:55 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Base de données |
| Affecte la/les version(s): | 13.0.0 |
| Version(s) corrigée(s): | 14.0.0 |
| Type: | Nouvelle fonctionnalité | Priorité: | Critique |
| Rapporteur: | Agathe Remy | Attribution: | Patrick Pereira |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Site: | Prod |
| Classif1: | DB |
| Classif2: | bi |
| Projets PM archivés: | Maintenance 14.x.x |
| Description |
|
Bonjour, Le Marketing ayant le droit de modifier le nom d'un tracking, il faut pouvoir tracer ces modifications afin de les intégrer dans la base de reporting. Pour cela, pouvez-vous ajouter un champ CHANGE_DATE dans la table USR_TRACKING? Merci:-) Agathe |
| Commentaires |
| Commentaire de Swan Desportes [ 19/mars/07 18:02 ] |
| Le marketing change les libellés depuis peu mais il n'y a aucun moyen de percevoir cette infomation niveau BI. L'implémentation de cette date est importante pour éviter de casser les rapports. |
| Commentaire de Alexandre Garnier [ 02/avr./07 18:43 ] |
| C'est fait |
| Commentaire de Younès Charrière [ 17/avr./07 18:30 ] |
| Agathe c'est bon pour toi ? |
| Commentaire de Ghislain Gridel [ 17/avr./07 18:37 ] |
| Impec. merci bcp. Ghislain |
| Commentaire de Agathe Remy [ 18/avr./07 17:23 ] |
|
Le champ CHANGE_DATE n'est pas en NOT NULL comme sur les autres tables... Est-ce normal? Si oui, pourquoi? Agathe |
| Commentaire de Alexandre Garnier [ 18/avr./07 17:31 ] |
|
le script est pourtant bien là : integ/04_POST_DEPLOY/OFFLINE/V14_0_0_ Pas passé ? |
| Commentaire de Patrick Pereira [ 18/avr./07 17:46 ] |
|
On passe les champ NOT NULL en POST_DEPLOY. Et donc, non, elle n'est pas encore NOT NULL. A voir avec l'integ pour le passage des scripts POST_DEPLOY, mais le processus suit son cours. |
| Commentaire de Younès Charrière [ 20/avr./07 15:02 ] |
|
Peux-tu passer le script en Integ Patrick stp ? Merci. |
| Commentaire de Patrick Pereira [ 20/avr./07 15:48 ] |
| C'est fait en Integ. |
| Commentaire de Agathe Remy [ 20/avr./07 15:55 ] |
|
C'est OK pour moi. Agathe |
[APP-11459] BI : mise en place d'un flux incrémental sur USR_SUBSCRIPTION Création: 27/juil./06 18:05 Mise à jour: 25/juin/07 18:42 Résolue: 04/août/06 16:18 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Base de données, News Letters |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 9.0.3 |
| Type: | Amélioration | Priorité: | Critique |
| Rapporteur: | Agathe Remy | Attribution: | Geneviève Beaujard |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Bonjour, Afin de permettre la mise en place du partenariat avec 1000Mercis pour les actions Marketing, nous aurions besoin de leur transférer quotidiennement toutes les mises à jour des informations d'abonnement et désabonnement. Pour éviter de leur transférer toutes les données de la table USR_SUBSCRIPTION tous les jours, nous aimerions bénéficier d'une change_date qui nous indiquerait les modifications (désincriptions) des données. Merci:-) Agathe |
| Commentaires |
| Commentaire de Patrick Condevaux [ 27/juil./06 19:36 ] |
| qui se charge de ca.... |
| Commentaire de Quentin de Chivré [ 27/juil./06 19:39 ] |
|
USR_SUBSCRIPTION Name Null? Type ----------------------------------------------------------------------------------- -------- -------------------------------------------------------- USR_SUBSCRIPTION_ID NOT NULL NUMBER(20) USER_ACCOUNT_ID NOT NULL NUMBER(20) USS_TYPE_CODE NOT NULL NUMBER(5) CREATION_DATE DATE ROW_VERSION NUMBER(20) Je suggère d'ajouter une colonne DELETION_DATE (comme dans COMMISSION_RULE) Ainsi, lors de la création de compte, si je m'abonne une newsletter => INSERT dans la table si je ne m'abonne pas => rien Ultérieurement si je m'abonne une newsletter => INSERT dans la table si je me désabonne => UPDATE de DELETION_DATE Encore plus tard si je me ré-abonne => 1/ nouvel INSERT dans la table, 2/ ou plutot UPDATE de DELETION_DATE a NULL ?? 1/ - Permet de garder tout l'historique (mais on l'a dans les evenements aussi) - Implique de changer les requetes dans la table (flux EMV, reporting, synchro BI, ....) pour prendre en compte la DELETION_DATE et aussi pour dédoublonner en ne prenant en compte que la ligne la + récente pour un abonnement donné => BOF 2/ - Pas tres clean de de-supprimer une ligne... - Implique tjs de changer les requetes dans la table, mais pas de dédoublonnement => Donc mieux |
| Commentaire de Quentin de Chivré [ 27/juil./06 19:39 ] |
|
Cependant dans ce cas autant plutot faire du classique, a savoir : - Ajouter une colonne CHANGE_DATE - Ajouter une colonne USS_STATUS_CODE et une table correspondante avec 2 valeurs : SUBSCRIBED, NOT_SUBSCRIBED Ok c'est un peu lourd mais finalement c'est le plus générique et si jamais on veut rajouter des états ca sera simple (SUSPENDED, ...) et comme ca on reste dans du connu. Pour le coup on pourrait se demander s'il est utile d'inserer toutes les lignes lors de l'inscription, avec un état SUBSCRIBED ou NOT_SUBSCRIBED mais ca ne me parait pas une bonne idée. |
| Commentaire de Quentin de Chivré [ 27/juil./06 19:41 ] |
| Genevieve, peux tu faire ca ? C'est pour Agathe et elle en a besoin pour Septembre (903) |
| Commentaire de Judd OSullivan [ 31/juil./06 18:15 ] |
|
Donc on garde une ligne dans USR_SUBSCRIPTION même si l'utilisateur n'a plus de subscription. Et si l'utilisateur abonne il suffit plus d'inserer une ligne. Il faut chercher aussi une ligne existant dans un mode 'NOT_SUBSCRIBED' (d'ailleurs, je prefere SUBSCRIBED et UNSUBSCRIBED). |
| Commentaire de Quentin de Chivré [ 31/juil./06 18:30 ] |
| Ok pour le renommage, puisque en effet avec ce mode de fonctionnement on a forcémment été subscribed a un moment |
| Commentaire de Geneviève Beaujard [ 04/août/06 16:16 ] |
|
hecking in UserDetail.java; /home/cvs/dev/source/src/com/babelstore/user/UserDetail.java,v <-- UserDetail.java new revision: 1.42; previous revision: 1.41 done Checking in userentity.xml; /home/cvs/dev/source/src/com/babelstore/user/userentity.xml,v <-- userentity.xml new revision: 1.81; previous revision: 1.80 done Checking in back/UserSubscribeAction.java; /home/cvs/dev/source/src/com/babelstore/user/back/UserSubscribeAction.java,v <-- UserSubscribeAction.java new revision: 1.20; previous revision: 1.19 done Checking in business/SubscriptionBusiness.java; /home/cvs/dev/source/src/com/babelstore/user/business/SubscriptionBusiness.java,v <-- SubscriptionBusiness.java new revision: 1.1.74.1; previous revision: 1.1 done Checking in business/SubscriptionBusinessBean.java; /home/cvs/dev/source/src/com/babelstore/user/business/SubscriptionBusinessBean.java,v <-- SubscriptionBusinessBean.java new revision: 1.1.74.1; previous revision: 1.1 done Checking in business/SubscriptionBusinessHome.java; /home/cvs/dev/source/src/com/babelstore/user/business/SubscriptionBusinessHome.java,v <-- SubscriptionBusinessHome.java new revision: 1.1.74.1; previous revision: 1.1 done Checking in business/SubscriptionQuery.java; /home/cvs/dev/source/src/com/babelstore/user/business/SubscriptionQuery.java,v <-- SubscriptionQuery.java new revision: 1.2.36.1; previous revision: 1.2 done Checking in business/UserBusinessBean.java; /home/cvs/dev/source/src/com/babelstore/user/business/UserBusinessBean.java,v <-- UserBusinessBean.java new revision: 1.476.2.3; previous revision: 1.476.2.2 done |
| Commentaire de Geneviève Beaujard [ 04/août/06 16:18 ] |
|
Checking in SubscriptionInfo.java; /home/cvs/dev/source/generated/com/babelstore/user/SubscriptionInfo.java,v <-- SubscriptionInfo.java new revision: 1.4; previous revision: 1.3 done Checking in business/BaseSubscriptionInfoQuery.java; /home/cvs/dev/source/generated/com/babelstore/user/business/BaseSubscriptionInfoQuery.java,v <-- BaseSubscriptionInfoQuery.java new revision: 1.4; previous revision: 1.3 done RCS file: /home/cvs/dev/source/generated/com/babelstore/user/business/SubscriptionInfoSelector.java,v done Checking in business/SubscriptionInfoSelector.java; /home/cvs/dev/source/generated/com/babelstore/user/business/SubscriptionInfoSelector.java,v <-- SubscriptionInfoSelector.java initial revision: 1.1 done Checking in business/UsrSubscriptionEntityBean.java; /home/cvs/dev/source/generated/com/babelstore/user/business/UsrSubscriptionEntityBean.java,v <-- UsrSubscriptionEntityBean.java new revision: 1.6; previous revision: 1.5 done Checking in business/subscriptionbusiness-ejb-jar-structural.xml; /home/cvs/dev/source/generated/com/babelstore/user/business/subscriptionbusiness-ejb-jar-structural.xml,v <-- subscriptionbusiness-ejb-jar-structural.xml new revision: 1.4; previous revision: 1.3 done Checking in business/subscriptionbusiness-jbosscmp-jdbc.xml; /home/cvs/dev/source/generated/com/babelstore/user/business/subscriptionbusiness-jbosscmp-jdbc.xml,v <-- subscriptionbusiness-jbosscmp-jdbc.xml new revision: 1.4; previous revision: 1.3 done RCS file: /home/cvs/dev/source/generated/com/babelstore/user/code/UssStatusCode.java,v done Checking in code/UssStatusCode.java; /home/cvs/dev/source/generated/com/babelstore/user/code/UssStatusCode.java,v <-- UssStatusCode.java initial revision: 1.1 done |
| Commentaire de Judd OSullivan [ 07/août/06 14:26 ] |
|
Certains fichier ont été checkiné sur le branch BRANCH_V902 donc je checkin ces fichiers sur le tronc. /home/cvs/dev/source/src/com/babelstore/user/business/SubscriptionBusiness.java,v <-- SubscriptionBusiness.java new revision: 1.2; previous revision: 1.1 done Checking in business/SubscriptionBusinessBean.java; /home/cvs/dev/source/src/com/babelstore/user/business/SubscriptionBusinessBean.java,v <-- SubscriptionBusinessBean.java new revision: 1.2; previous revision: 1.1 done Checking in business/SubscriptionBusinessHome.java; /home/cvs/dev/source/src/com/babelstore/user/business/SubscriptionBusinessHome.java,v <-- SubscriptionBusinessHome.java new revision: 1.2; previous revision: 1.1 done Checking in business/SubscriptionQuery.java; /home/cvs/dev/source/src/com/babelstore/user/business/SubscriptionQuery.java,v <-- SubscriptionQuery.java new revision: 1.3; previous revision: 1.2 done Checking in business/UserBusinessBean.java; /home/cvs/dev/source/src/com/babelstore/user/business/UserBusinessBean.java,v <-- UserBusinessBean.java new revision: 1.479; previous revision: 1.478 |
| Commentaire de Quentin de Chivré [ 07/août/06 16:15 ] |
|
Comment eviter cela ? Y a t'il moyen de bloquer les check
ins sur une branche une fois celle ci mergée dans le tronc ? Si on ne peut pas le bloquer, peut etre un petit script pour regarder s'il y a eu des check ins post merge que l'on execute dans les jours qui suivent le merge ? |
| Commentaire de Judd OSullivan [ 07/août/06 16:50 ] |
|
On peut difficilement bloquer ces check-ins. Mais en même
temps c'est une nouvelle manipulation pour les devs donc avec un peu
plus d'experience on devrait avoir moins de ce gendre de problème. Je vais mettre dans notre guide de déploiement une tâche verification des checkins sur le branch après le tag. Le script history_between_tags devrait marcher pour ca. |
| Commentaire de Patrick Condevaux [ 08/sept./06 15:02 ] |
| ok en INTEG |
[BIN-54] BI : Recall Création: 20/mars/06 13:44 Mise à jour: 14/sept./07 16:58 Echéance: 20/mars/06 00:00 Résolue: 21/mars/06 10:52 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Agathe Remy | Attribution: | Samir Beghdadi |
| Résolution: | Corrigé | ||
| Estimation restante: | 55 minutes | ||
| Temps consacré: | 5 minutes | ||
| Estimation originale: | 1 heure | ||
| Description |
|
rapport : New children after mailing - Onglet "New children after mailing" : libellé de colonne "Contact count" à remplacer par "Contacts count" rapport : New sellers after mailing - libellé de colonne "Advert on-line count" à remplacer par "On-line adverts" - centrer le titre |
| Commentaires |
| Commentaire de Samir Beghdadi [ 20/mars/06 13:59 ] |
| C fait |
| Commentaire de Samir Beghdadi [ 21/mars/06 10:52 ] |
| C fait |
[cob] META-TACHE Fermeture cobs Mobilesachat, Free Surf, France Mobile, Midi Libre, Nice Matin
(APP-25098)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 52.0.0 (CTN-M) |
| Type: | Sous-tâche | Priorité: | Mineur |
| Rapporteur: | Fabrice Feugas | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM: | *** RESERVE *** |
| Description |
|
Nettoyer le code côté BI des cobs cités dans le titre et qui ont été arrêtés.
|
| Commentaires |
| Commentaire de Agathe Remy [ 30/avr./09 11:41 ] |
| Intégration des emails dans le flux Pn Data prévue pour le flux mensuel du 02/07 |
| Commentaire de Cyril Tanneau [ 01/juil./09 12:29 ] |
|
Bonjour, les emails des cobrandings inactifs ont bien été intégrés au flux PNDATA. Merci, Cyril Tanneau |
[INF-182] BI : Accès extérieur pour le téléphone de l'équipe BI Création: 09/oct./08 18:47 Mise à jour: 17/oct./08 14:56 Résolue: 17/oct./08 14:29 |
|
| Etat: | Résolu |
| Projet: | Infrastructure |
| Composants: | Téléphonie |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | Stéphane Eccli |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Bonjour, Le téléphone de l'équipe (01 42 78 94 61) n'est pas accessible depuis l'extérieur. Ceci pose un problème à nos partenaires qui ne peuvent doc pas joindre directement l'équipe en cas de besoin : - l'équipe de développement 1000Mercis a régulièrement besoin de joindre mes développeurs par téléphone; - les partenaires Assur'One, Pn Data, les chercheurs de Bristol et La Redoute ont également besoin de joindre Dalila régulièrement suite à des incidents ou pour poser des questions sur les évolutions/process. Merci. Agathe |
| Commentaires |
| Commentaire de Stéphane Eccli [ 17/oct./08 14:29 ] |
| ok |
| Commentaire de Agathe Remy [ 17/oct./08 14:56 ] |
| Merci:-) |
[DEC-610] [BI] Demande de rapport - nombre de comptes passés de visibilité -1 à 1 suite activation inventaire. Création: 16/oct./07 17:27 Mise à jour: 23/oct./07 10:36 Résolue: 17/oct./07 19:44 |
|
| Etat: | Fermé |
| Projet: | Reporting |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Cedric Favero | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Bug_visibilité_activation_inventairexls.xls
|
| Pays: |
FRA - France
|
| Description |
|
Nous avons constaté un bug recemment qui faisait qu'un
vendeur créant son compte , tombant en visibilité -1 (par mot clés)
pouvait repasser de lui meme en visibilité 1 simplement en activant son
inventaire. ( Il est apparu que la procédure d'activation de l'inventaire ne vérifiait pas la visiblité de l'inventaire (resolu en v17) Ces regles permettant de detecter de nombreuses fraudes ou de comptes suspectés de contrefaçon , il nous faudrait connaitre le nombre de comptes qui ont pu etre concernés sur les 6 derniers mois et nous aurions donc besoin d'un rapport. Business Objects n'étant pas en mesure de retracer les évenements , je passe par un JIRA pour obtenir un rapport BI dans la mesure du possible. Les évenements sont donc: création d'un compte sellver_visibility passée en -1 par mot clé envoi du mail d'activation de l'inventaire validation de l'inventaire par l'utilisateur passage en 1 ex de compte sur lequel le problème est intervenu: fred12camus j'insiste sur le fait que le la modification de la visilibté est faite par l'utilisateur et non par le BO sinon on va avoir tous les comptes repassés en 1 manuellement ce qui est notre processus normal. Merci d'avance. |
| Commentaires |
| Commentaire de Agathe Remy [ 17/oct./07 10:17 ] |
|
Cédric, Si je comprends bien, tu veux la liste des comptes repassés en visibilité 1 suite à l'activation de l'inventaire au cours des 6 derniers mois. Est-ce bien cela? Agathe |
| Commentaire de Cedric Favero [ 17/oct./07 10:23 ] |
|
oui c'est bien çà mais il faut qu'ils soient tombés en -1 au préalable. Car quand tu crées un compte et actives ton inventaire tu passes bien de 0 à 1 Donc en clair: "comptes passés de visibilité -1 à visibilité 1 suite à l'activation de l'inventaire au cours des 6 derniers mois " |
| Commentaire de Agathe Remy [ 17/oct./07 19:43 ] |
|
Cédric, Tu trouveras dans le document ci-joint la liste des 585 user_account_id concernés par ce bug. Cordialement, Agathe |
| Commentaire de Agathe Remy [ 17/oct./07 19:43 ] |
|
La requête effectuée pour extraire la liste des comptes est la suivante : SELECT DISTINCT user_account.user_account_id FROM user_account, (SELECT creation_date, user_account_id FROM usr_event WHERE use_type_code=460 AND description LIKE '-1%' ) hide_event, (SELECT user_account_id, creation_date FROM usr_event WHERE use_type_code=460 AND description='1 Visible (Surveillé) (Activation)' ) visible_event WHERE user_account.usr_visibility_code=1 -- visibilité vendeur AND user_account.usr_activation_code=10 -- inventaire activé AND user_account.user_account_id=hide_event.user_account_id AND user_account.user_account_id=visible_event.user_account_id AND hide_event.creation_date<visible_event.creation_date ; Agathe |
| Commentaire de Cedric Favero [ 18/oct./07 09:40 ] |
|
Super. Après un petit regard , la requete est bonne et c'est exactement ce que je voulais... Je vais donc pouvoir regarder çà en détail . Merci beaucoup pour cette grande rapidité. |
BI Espagne : environnement de développement
(EXP-2886)
|
|
| Etat: | Fermé |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Sous-tâche | Priorité: | Mineur |
| Rapporteur: | Jérémie Bennejean | Attribution: | Jérémie Bennejean |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Commentaires |
| Commentaire de Jérémie Bennejean [ 27/mars/07 18:28 ] |
|
Agathe, bi.es.dev doit pointer sur quel serveur ? |
| Commentaire de Agathe Remy [ 27/mars/07 18:58 ] |
| ??? |
[BIN-236] [Cobrand MidiLibre] Extraction BI Création: 01/déc./06 17:05 Mise à jour: 14/sept./07 17:32 Echéance: 12/janv./07 00:00 Résolue: 30/janv./07 10:35 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Richard Dubois | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Sur la base de la nouvelle remuneration, mettre en place les reports pour GGR Date de mise en prod possible pour la semaine du 8 au 12 janvier 07 |
| Commentaires |
| Commentaire de Ghislain Gridel [ 01/déc./06 17:13 ] |
|
Les rapports sont à adreser à : Pour Midi Libre : agiraudo@midilibre.com Merci Ghislain |
[EXP-3116] BI : modification de l'alias reporting@priceminister.com Création: 22/déc./06 15:08 Mise à jour: 25/juin/07 19:00 Résolue: 02/janv./07 10:23 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Nouvelle fonctionnalité | Priorité: | Mineur |
| Rapporteur: | Agathe Remy | Attribution: | ZZ_Arnaud Baali |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Suite au départ de Moahmed et à l'arrivée de romain, serait-il possible de mettre à jour l'alias reporting@priceminister.com afin d'y remplacer mohamed.ezzouak@priceminister.com par romain.czornomaz@priceminister.com. Merci:-) Agathe |
| Commentaires |
| Commentaire de Patrice Boulanger [ 28/déc./06 10:45 ] |
|
Arnaud, Merci de voir pour cette demande. |
| Commentaire de ZZ_Arnaud Baali [ 02/janv./07 10:23 ] |
| La demande sera active dans la journée |
[INF-205] [BI] : Retour de Florian AMBROSI Création: 17/nov./08 11:25 Mise à jour: 04/déc./08 17:46 Résolue: 04/déc./08 17:46 |
|
| Etat: | Résolu |
| Projet: | Infrastructure |
| Composants: | Micro |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | Christophe Garcia |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
FICHE DE PROFIL FAM - 2008.doc
|
| Description |
|
Bonjour, Florian AMBROSI, notre stagiaire en alternance les lundis et mardis, est de retour parmi nous jusqu'au 31 mars 2009:-) S'il te plait, serait-il donc possible de lui donner les droits d'administrateur sur son poste afin qu'il puisse utiliser nos applictifs. D'autre part, peux-tu vérifier qu'il est bien dans l'alias biteam@priceminister.com ? Enfin, tu peux récupérer le poste à côté de mon bureau. Merci. Agathe PS : Désolée pour le retard, la semaine dernière fut vraiment trop courte:-( Je ferai mieux la prochaine fois! |
| Commentaires |
| Commentaire de Stéphane Eccli [ 17/nov./08 11:57 ] |
|
les comptes n'avaient pas été supprimés, je l'ai ajouter a la ML. reste a voir le compte Jira |
| Commentaire de Agathe Remy [ 17/nov./08 12:08 ] |
|
Nous avons déjà testé le compte JIRA : c'est ok. Agathe |
[EXP-1195] Envoi de mail Pommery avec BI Création: 07/févr./06 13:16 Mise à jour: 25/juin/07 18:56 Echéance: 08/févr./06 00:00 Résolue: 08/févr./06 15:16 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Pap Ndiaye | Attribution: | Pap Ndiaye |
| Résolution: | Corrigé | ||
| Estimation restante: | 0 minutes | ||
| Temps consacré: | 1 heure | ||
| Estimation originale: | 1 heure | ||
[BIN-113] ajout sur les rapports BI recall Création: 29/juin/06 11:21 Mise à jour: 14/sept./07 17:04 Résolue: 29/juin/06 17:15 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Critique |
| Rapporteur: | Odile Szabo | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | 2 heures | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | 2 heures | ||
| Description |
|
Samir, peux tu ajouter les nouveaux acheteurs dans le taleau "news buyers after mailing" et les nouveaux vendeurs dans le tableau "news sellers after mailing", mois par mois. |
| Commentaires |
| Commentaire de Samir Beghdadi [ 29/juin/06 17:15 ] |
|
Je te confirme l'ajout des deux champs "New buyers count" et
"New sellers count" dans les deux tableaux respectivement "New buyers
after mailing" et "News sellers after mailing" Cdt |
[EXP-667] BI : demande d'installation de l'ARKOON Création: 22/déc./05 16:55 Mise à jour: 25/juin/07 18:55 Résolue: 23/déc./05 13:05 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Bloquant |
| Rapporteur: | Agathe Remy | Attribution: | Jérémie Bennejean |
| Résolution: | Corrigé | ||
| Σ Estimation restante: | 0 minutes | Estimation restante: | 0 minutes |
| Σ Temps consacré: | 30 minutes | Temps consacré: | 30 minutes |
| Σ Estimation originale: | Non spécifié | Estimation originale: | Non spécifié |
| Sous-tâches: |
|
| Description |
|
Bonjour, Serait-il possible d'installer l'ARKOON sur mon poste (demander un certificat à Jet Multimedia) ?! Merci:-) Agathe |
| Commentaires |
| Commentaire de Jérémie Bennejean [ 23/déc./05 13:05 ] |
| Fais avec le profil d 'emmenuelle lachampe |
[EXP-1309] BI : arrivée d'un prestataire Création: 17/févr./06 19:08 Mise à jour: 25/juin/07 18:56 Résolue: 21/févr./06 17:15 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Installation |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Agathe Remy | Attribution: | ZZ_Arnaud Baali |
| Résolution: | Corrigé | ||
| Estimation restante: | 1 heure | ||
| Temps consacré: | 3 heures | ||
| Estimation originale: | 4 heures | ||
| Description |
|
Comme convenu, voici une demande pour l'installation du
poste de Cyrille SARTI d'IDB Consulting pour mercredi 22 février 2006. Merci. Agathe |
| Commentaires |
| Commentaire de ZZ_Arnaud Baali [ 20/févr./06 10:06 ] |
| Le compte mail est en cours de création |
[Cobrand MidiLibre] Metatache
(APP-13968)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Cobrandings |
| Affecte la/les version(s): | 11.1.0 (La Redoute) |
| Version(s) corrigée(s): | 12.0.0 |
| Type: | Sub-bug | Priorité: | Critique |
| Rapporteur: | Richard Dubois | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM archivés: | COB Midi Libre |
| Description |
|
Sur la base de la nouvelle remuneration, mettre en place les reports pour GGR Date de mise en prod possible pour la semaine du 8 au 12 janvier 07 |
| Commentaires |
| Commentaire de Ghislain Gridel [ 01/déc./06 16:48 ] |
|
Les rapports sont à adreser à : Pour Lycos : jerome.lepage@lycos-europe.com Pour Midi Libre : agiraudo@midilibre.com Merci Ghislain |
| Commentaire de Ghislain Gridel [ 03/janv./07 10:24 ] |
|
Le rapport Midi Libre est un rapport type LRO. Ghislain |
| Commentaire de Patrick Condevaux [ 05/févr./07 16:44 ] |
| ok |
[META-TACHE] Projet [VVV]
(APP-16788)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Produits |
| Affecte la/les version(s): | 15.1.2 |
| Version(s) corrigée(s): | 16.0.0 |
| Type: | Sub-new feature | Priorité: | Mineur |
| Rapporteur: | Sébastien Aubert | Attribution: | Romain Czornomaz |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM archivés: | Vendez le vôtre - Vêtement |
| Description |
|
Pour pouvoir avoir une idée du nombre de FP supplémentaires
qui seront générées suite à la mise en place du nouveau process, il
faudrait connaître le "Nombre moyen de vendeurs différents par FP
actives avec annonce"
|
| Commentaires |
| Commentaire de Romain Czornomaz [ 30/juil./07 15:16 ] |
|
Seb, Alors voici ton resultat du nombre moyen de vendeurs différents ayant des annonces visibles, suspendues, fermées et FP actives: 1.19736621867769408753015310392359572687 En gros ca fait 1 :) Bonne journée, Romain |
| Commentaire de Sébastien Aubert [ 31/juil./07 11:26 ] |
| ok merci |
[META-TACHE] Projet [VVV]
(APP-16788)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Produits |
| Affecte la/les version(s): | 15.1.2, 17.0.0 |
| Version(s) corrigée(s): | 18.0.0 |
| Type: | Sub-new feature | Priorité: | Mineur |
| Rapporteur: | Sébastien Aubert | Attribution: | Romain Czornomaz |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM archivés: | Vendez le vôtre - Vêtement |
| Description |
|
Pour pouvoir avoir une idée du nombre de FP supplémentaires
qui seront générées suite à la mise en place du nouveau process, il
faudrait connaître le "Nombre moyen de vendeurs différents par FP
actives avec annonce"
|
| Commentaires |
| Commentaire de Romain Czornomaz [ 09/nov./07 16:08 ] |
|
Salut, J'ai refait le calcul pour connaitre le nombre moyen de vendeurs différents par FP actives avec annonce, et j'obtiens desormais... roulement de tanbours... environ 1.15 vendeurs / FP. Je cloture la demande, n'hesitez pas à la réouvrir Seb ou Benoit si vous souhaitez plus d'infos. Bonne journée, Romain |
[EXP-2482] BI : le reporting n'a pas démarré ce matin Création: 27/juil./06 16:54 Mise à jour: 25/juin/07 18:58 Résolue: 08/août/06 10:23 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Agathe Remy | Attribution: | Edouard Laurent |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Le cron a bien lancé le pmreportsconductor.sh, mais il
semble que le script de validation de la synchro
(/data/priceminister/mafal/pmtopforreports.pl) n'a pas reçu le signal de
fin de synchro... A investiguer... |
| Commentaires |
| Commentaire de Antoine Koener [ 27/juil./06 18:32 ] |
|
gogogo ! |
[EXP-2338] BI : accès direct à phaeton depuis latone Création: 26/juin/06 17:54 Mise à jour: 25/juin/07 18:58 Résolue: 27/juin/06 10:40 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Flux |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | Jérémie Bennejean |
| Résolution: | Corrigé | ||
| Estimation restante: | 0 minutes | ||
| Temps consacré: | 30 minutes | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Bonjour, Nous aimerions pouvoir accéder directement depuis latone à phaeton sans renseigner à nouveau le mot de passe lorsqu'on fait un ssh adminpm@phaeton. Ce dispositif est déjà en place sur titan. Merci:-) Agathe |
| Commentaires |
| Commentaire de Jérémie Bennejean [ 27/juin/06 10:40 ] |
|
La demande est en place. J'ai générée la clé ssh id_dsa.pub sur latone et l'ai mis dans l'authorized_key de phaeton J'ai testé et montré à François, cela fonctionne. Jeremie |
[BIN-235] [Cobrand Lycos Occasion] Extraction BI Création: 01/déc./06 17:03 Mise à jour: 14/sept./07 17:32 Echéance: 22/déc./06 00:00 Résolue: 05/janv./07 12:40 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Richard Dubois | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Description |
|
Sur la base de l'ancienne remuneration, mettre en place les reports pour GGR Date de mise en prod prévue pour la semaine du 18 au 22 Décembre. |
| Commentaires |
| Commentaire de Agathe Remy [ 18/déc./06 17:39 ] |
|
Ghislain, Peux-tu me communiquer l'adresse email du destinataire? De plus peux-tu me donner la semaine de premier envoi du rapport (après la mise en prod, sinon pas de données) et me confirmer qu'il s'agit bien du reporting ancienne rémunération? Merci:-) Agathe |
| Commentaire de Ghislain Gridel [ 18/déc./06 18:10 ] |
|
Il faut envoyer le rapport la semaine du 8 janvier à : jerome.lepage@lycos-europe.com Il s'agit du rapport ancienne rémunération. Ghislain |
| Commentaire de Agathe Remy [ 05/janv./07 12:40 ] |
|
Le reporting hebdo a été mis en place. Le premier rapport devrait être envoyé dimanche en fin de matinée. Cordialement, Agathe |
[BIN-234] [Cobrand Lycos Occasion] Extraction BI Création: 01/déc./06 17:03 Mise à jour: 14/sept./07 17:32 Résolue: 04/déc./06 18:44 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Richard Dubois | Attribution: | Agathe Remy |
| Résolution: | Invalid | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Sur la base de l'ancienne remuneration, mettre en place les reports pour GGR Date de mise en prod prévue pour la semaine du 18 au 22 Décembre. |
[INF-25] problème pour genérer les rapports BI - java? Création: 20/nov./07 12:59 Mise à jour: 16/avr./08 17:23 Résolue: 16/avr./08 17:23 |
|
| Etat: | Résolu |
| Projet: | Infrastructure |
| Composants: | Micro |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Henrieta Bubenkova | Attribution: | Patrice Boulanger |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Bonjour, J'ai un problème en me connectant à Business Objects, je n'arrive pas à lancer des nouveaux rapports, ça rame et apparemment c'est lié à mon ordinateur car les autres n'ont pas le même souci. Cela peut être du à ma version Java où je ne sais plus, il faut voir. Comme j'ai vraiment besoin de m'en servir régulièrement, c'est assez urgent pour moi. Merci d'avance. Henrieta |
| Commentaires |
| Commentaire de Stéphane Eccli [ 16/avr./08 17:23 ] |
|
demande a refaire si le problème persiste. Henrieta n'en a pas refait depuis. |
[BIN-444] [Affiliation] : Automatisation de rapport BI hebdomadaire Création: 22/mai/08 12:28 Mise à jour: 26/juin/08 15:57 Résolue: 30/mai/08 17:05 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Nouvelle fonctionnalité | Priorité: | Majeur |
| Rapporteur: | Jonathan Gorges | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Toujours en vue d'optimiser notre productivité, nous voudrions automatiser un rapport en Affiliation. Il s'agit du rapport "PriceMinister - Affiliation purchase checking" présent ici : Dossiers publics > France > Affiliation. Voici notre demande : -> Nous avons besoin de générer 3 rapports automatisés tous les Lundi matin (vers 10h, une fois que les données sont consolidées) en vue de valider les ventes des affiliés. -> Un rapport pour le Groupe de Tracking : Affiliationx -> Un rapport pour le Groupe de Tracking : Cibleclickx -> Un rapport pour le Groupe de Tracking : Zanoxx La date "Select authorization date" qui nous intéresse est "le mois dernier". Par exemple : le lundi 19 Mai, le rapport devra couvrir du 18/04 au 18/05. Je viens vous voir pour en parler de vive voix... (un peu compliqué par Jira j'ai l'impression...). Merci d'avance pour votre retour. |
| Commentaires |
| Commentaire de Agathe Remy [ 22/mai/08 20:17 ] |
|
Pas de pb Jonathan:-) Mais à qui veux-tu les envoyer? Agathe |
| Commentaire de Jonathan Gorges [ 23/mai/08 09:22 ] |
|
Hello, Merci Agathe pour ce retour rapide. Pour le moment, je voudrais l'envoyer sur mon adresse jonathan.gorges@priceminister.com et sur celle de Ghislain (ghislain.gridel@priceminister.com). Dès que le nouveau stagiaire prendra ma place :-(... nous changerons mon adresse pour la remplacer par la sienne. Merci. Jon. |
| Commentaire de Cyril Tanneau [ 23/mai/08 12:19 ] |
|
Bonjour Jonathan, Sous quel format doivent être restitués les rapports (BO, Excel, PDF)? Merci, Cyril |
| Commentaire de Jonathan Gorges [ 30/mai/08 17:16 ] |
|
Merci bcp pour tout ça ! Il manque plus que le nouveau stagiaire maintenant :-) ! |
| Commentaire de Cyril Tanneau [ 02/juin/08 18:07 ] |
|
Le rapport est désormais en production sous le nom "Partner -
Affiliation Purchase checking", dans le dossier "France\Affiliation". Nous lui avons assigné un nouveau nom, afin que le rapport "PM - Affiliation Purchase checking" soit toujours disponible, ce rapport permettant la sélection de la période d'autorisation. Le rapport est programmé chaque Lundi matin: - 10h00: Groupe de trackings Zanoxx - 10h10: Groupe de trackings Affiliationx - 10h20: Groupe de trackings Cibleclickx. Les rapports édités seront adressés au format Excel par e-mail à Ghislain (ghislain.gridel@priceminister.com) et Jonathan (jonathan.gorges@priceminister.com). L'objet contiendra: le groupe de trackings, le nom du rapport et la date de rafraichissement. Merci, Cyril |
| Commentaire de Ghislain Gridel [ 03/juin/08 09:34 ] |
| merci Cyril |
[BIN-541] [Marketing] : descriptif "real buyer" sous Bi Création: 07/janv./09 19:25 Mise à jour: 28/janv./09 20:09 Résolue: 09/janv./09 17:21 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Bug & Improvement |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Thomas Beylot | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Hello il faudrait plutôt que de dire seulement que real buyer correspond à count of buyer account préciser que c'est sur du capturé uniquement merci |
| Commentaires |
| Commentaire de Cyril Tanneau [ 09/janv./09 17:21 ] |
|
Bonjour, la description de l'indicateur 'Real buyer count' a bien été modifiée dans les Univers ITEM, PURCHASE et USER ACCOUNT en France et en Espagne. Nous avons désormais comme description: Buyer count with at least one captured transaction (confirmed by the seller, under claim or closed). Merci, Cyril |
[EXP-4591] [Alimentation BI] : temps d'attente entre les mappings Création: 27/oct./08 14:49 Mise à jour: 26/nov./08 10:47 Résolue: 26/nov./08 10:47 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Troubleshooting |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | Ayoub Benseghir |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
alim_ODS.png
Etude_temps_ALIM_ODS_ITM.xls
|
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Depuis la fin de la semaine dernière, nos durées d'exécution des processflows d'alimentation de l'ODS ont augmenté. Après analyse, il s'avère que les durées d'exécution des mappings n'ont pas évolué, en revanche le temps d'exécution global du processflow a presque doublé?! Ce sont donc les traitements intermédiaires qui semblent plus longs. Hors nous n'avons à priori aucun levier (en tout cas au niveau de nos développements) sur ces traitements. Nous n'avons pas touché à ces traitements depuis plus de 2 semaines et ce qui est encore plus étrange, c'est que ce phénomène ne semble toucher que la partie ODS (et non les alimentations DWH et DTM). S'il vous plait, pourriez-vous nous aider à comprendre ce qui se passe? Agathe |
| Commentaires |
| Commentaire de Agathe Remy [ 27/oct./08 14:51 ] |
|
Vous trouverez dans le fichier ci-joint un exemple d'un
processflow dont la durée d'exécution a fortement augmenté. Vous pourrez
constater qu'il en est de même pour l'alimentation Espagne avec un jour
d'avance. Agathe |
| Commentaire de Agathe Remy [ 27/oct./08 14:54 ] |
|
Ayoub, Les processflows sont lancés à partir d'OEM. Comme vu avec Patrick, peux-tu regarder au niveau d'OEM s'il nous pouvons observer quelque chose? Merci. Agathe |
| Commentaire de Agathe Remy [ 27/oct./08 14:57 ] |
|
Pour information, nous nous sommes d'abord orientés vers un
problème de statistiques des schémas RT_FR et RT_ES (sur l'instance DW)
qui gèrent les méta-données d'exécutions des mappings et des
processflows d'OWB. De même, nous avons analysé le schéma OWF_MGR sur l'instance OWREP qui contient les méta-données du workflow serveur. Mais ces actions ont été sans effet sur le problème. Agathe |
| Commentaire de Agathe Remy [ 06/nov./08 18:47 ] |
|
Voici une courbe de supervision qui montre bien le problème... Agathe |
| Commentaire de Agathe Remy [ 25/nov./08 11:30 ] |
|
En cherchant avec Julien ce qui pouvait se passer entre
l'exécution des mappings, nous avons identifier des requêtes sur les
méta-données OWB lancées par le workflow server. Parmi ces requêtes, nous en avons identifier une qui nous semblait particulièrement longue (~40 sec en Prod au lieu de 1 ou 2 sec en Dév) dans le schéma RT_FR sur DW: SELECT MAX (audit_execution_id) FROM wb_rt_audit_executions WHERE ( (parent_audit_execution_id IS NULL AND 5028894 IS NULL) OR parent_audit_execution_id = 5028894 ) AND external_audit_id = 329829 ; Il s'avère que cette requête passe par un index (WB_RT_IDX_EX_EK) en Dév et fait un full scan en Prod. Ce qui est très étrange, c'est que le plan d'exécution proposé par le « set autot trace explain » passe bien par l'index, mais celui de l'exécution fait un full scan. Nous avons essayé de forcer le passage par l'index en Prod, mais sans succès. Lors de son exécution, la requête fait toujours un full scan ?!!! |
| Commentaire de Agathe Remy [ 25/nov./08 11:35 ] |
|
Au final, Patrick nous a suggéré de créé un nouvel index à 3 colonnes : create index WB_RT_IDX_EX_OPT on wb_rt_audit_executions (external_audit_id, parent_audit_execution_id, audit_execution_id) compute statistics tablespace RTS_IX; Cela fonctionne!!! Nos tests semblent montrer que les temps d'attente ont disparu:-) J'ai donc créé cet index sur RT_FR et RT_ES. A vérifier lors de la prochaine alimentation. Nous espérons que solution très pragmatique va résoudre le problème de ce JIRA. En revanche, nous constatons un phénomène vraiment étrange de décalage entre les plans d'exécutions prévus et ceux réellement exécutés qui rend vraiment compliquée toute optimisation : cf JIRA |
| Commentaire de Julien Girardet [ 26/nov./08 10:47 ] |
|
L'alimentation de cette nuit confirme l'utilité de cet index. Les temps d'attente ont disparu Je ferme le JIRA Julien. |
[EXP-370] BI : toujours pas de mail pour le consultant Keyrus! Création: 18/nov./05 17:42 Mise à jour: 25/juin/07 18:54 Résolue: 18/nov./05 17:55 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | Pap Ndiaye |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Bonjour, Petit Jira de relance parce qu'Eric Di Bennedetto n'a toujours pas d'email alors que cela fait plus de 3 semaines qu'il est arrivé... Son email devait être keyrus_owb@priceminister.com. Merci:-) |
| Commentaires |
| Commentaire de Pap Ndiaye [ 18/nov./05 17:55 ] |
| c fait |
[EXP-1564] BI : déplacement du poste de Cyrille SARTI Création: 20/mars/06 16:29 Mise à jour: 25/juin/07 18:57 Résolue: 21/mars/06 12:03 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Installation |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | ZZ_Arnaud Baali |
| Résolution: | Corrigé | ||
| Estimation restante: | 0 minutes | ||
| Temps consacré: | 15 minutes | ||
| Estimation originale: | 15 minutes | ||
| Description |
|
Bonjour, Serait-il possible de déplacer le poste de Cyrille SARTI à l'une des places libres sur le bureau derrière le nôtre? Merci:-) Agathe |
[EXP-4583] [Reporting BI] : Optimisation des rapports de cobranding Création: 21/oct./08 18:35 Mise à jour: 12/janv./11 11:12 Résolue: 12/janv./11 11:12 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Agathe Remy | Attribution: | Ayoub Benseghir |
| Résolution: | Aucune correction envisagée | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
cobranding_overview.sql
cobranding_purchase_sales.sql
|
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Tous les dimanches, nous générons un reporting hebdo à destination de nos partenaires cobranding avec leur activité de la semaine et un récapitulatif des 6 derniers mois. Certaines requêtes de ces rapports sont trop longues (plus de 10mn). Nous aimerions donc que vous nous aidiez à optimiser leur durée d'exécution. Merci pour de nous apporter vos lumières:-) Agathe |
| Commentaires |
| Commentaire de Agathe Remy [ 21/oct./08 18:57 ] |
|
Bonjour, Vous trouverez dans le fichier ci-joint la 1ère requête dont la durée d'exécution est trop longue. Agathe |
| Commentaire de Agathe Remy [ 21/oct./08 18:57 ] |
|
Bonjour, Vous trouverez dans le fichier ci-joint la 2ème requête dont la durée d'exécution est trop longue. Agathe |
| Commentaire de Ayoub Benseghir [ 28/oct./08 14:09 ] |
|
Bonjour, Le seul moyen d'optimiser ces requêtes est de créer un index multicolonne sur TF_ITEM pour chacune d'entre elle (avec ce que ca aura comme conséquence sur l'alim). En même temps 10-15min pour un traitement hebdo généré le dimanche (donc probablement pas utilisé avant lundi) est-ce vraiment grave? Ayoub |
| Commentaire de Ayoub Benseghir [ 03/déc./10 12:06 ] |
| Toujours d'actualité? |
[INF-616] Besoin pc au BI pour install BO Création: 14/janv./11 14:47 Mise à jour: 26/janv./11 15:11 Résolue: 26/janv./11 15:11 |
|
| Etat: | Résolu |
| Projet: | Infrastructure |
| Composants: | Micro |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Julien Girardet | Attribution: | Stéphane Eccli |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Hello,
Comme discuté à l'instant, j'ai besoin d'un pc (temporairement) pour installer le client BO le temps de la migration de Business Objects R3.1, c'est à dire pendant Q1. Merci Julien. |
| Commentaires |
| Commentaire de Stéphane Eccli [ 26/janv./11 15:11 ] |
| done. |
[Cobrand] Lycos Occasion metatache
(APP-13834)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Cobrandings |
| Affecte la/les version(s): | 11.2.0 (Lycos) |
| Version(s) corrigée(s): | 11.2.0 (Lycos) |
| Type: | Sub-bug | Priorité: | Mineur |
| Rapporteur: | Richard Dubois | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Projets PM archivés: | COB Lycos | ||||||||
| Description |
|
Sur la base de l'ancienne remuneration, mettre en place les reports pour GGR Date de mise en prod prévue pour la semaine du 18 au 22 Décembre. |
[Suppression COB] BambinOccasion et VirginMega
(APP-15134)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Cobrandings |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | ToDo |
| Type: | Sub-bug | Priorité: | Mineur |
| Rapporteur: | Richard Dubois | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Projets PM archivés: | COB Suppression COB obsolètes |
| Description |
|
Agathe, merci (si ce n'est pas déjà fait) d'arréter d'envoyer les rapports pour BambinOccasion et VirginMega. Merci |
[APP-18364] BI : Mise en ligne d'offre d'emploi Création: 29/oct./07 11:28 Mise à jour: 05/nov./07 15:34 Résolue: 05/nov./07 15:34 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aide en ligne, Infoglue |
| Affecte la/les version(s): | 17.1.1 |
| Version(s) corrigée(s): | 17.2.0 |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | Olga Costa |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Ciblage Emailing.doc
Concepteur Developpeur BI.doc
|
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Voici 2 offres d'emploi que j'aimerais diffuser sur le site dans la rubrique « PriceMinister recrute ». Merci:-) Agathe |
| Commentaires |
| Commentaire de Ariane Baldinger [ 30/oct./07 10:14 ] |
|
Olga, Peux-tu t'en occuper stp ? |
| Commentaire de Olga Costa [ 31/oct./07 11:57 ] |
|
Agathe, j'ai mis les annonces. Tu peux les voir ici http://bo.pm.bollinger:3180/help?action=c Si c'est ok pour toi, je soumets à publication. Merci |
[APP-18584] BI : règle de calcul du prix conseillé Création: 20/nov./07 11:52 Mise à jour: 26/nov./07 07:52 Résolue: 23/nov./07 10:12 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Produits |
| Affecte la/les version(s): | 17.2.1 |
| Version(s) corrigée(s): | 18.0.0 |
| Type: | Nouvelle fonctionnalité | Priorité: | Critique |
| Rapporteur: | Agathe Remy | Attribution: | Geneviève Beaujard |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM: | *** RESERVE *** |
| Classif1: | MEV |
| Description |
|
Bonjour, Dans le cadre de la mise en place de la campagne CRM "Mise en vente trop chère, trop longtemps", le Marketing a défini un critère de ciblage "annonce dont le prix de vente est supérieur au montant de la transaction moyenne observée depuis 6 mois". Nous aimerions donc savoir si ce "montant de la transaction moyenne observée depuis 6 mois" est stocké dans la base de données et quelles sont les régles de calcul associées. Pourrait-on avoir les mêmes informations pour le prix de vente conseillé? Merci:-) Agathe |
| Commentaires |
| Commentaire de Geneviève Beaujard [ 23/nov./07 10:12 ] |
|
Nous aimerions donc savoir si ce "montant de la transaction
moyenne observée depuis 6 mois" est stocké dans la base de données et
quelles sont les régles de calcul associées: Non ce montant n'est pas stocké dans la base. Il est calculé dans BaseProductModel dans la variable mAvgSalePrice: - lors de la soumission d'annonces (MEV rapide) à partir d'une fiche produit - lors de la creation d'un souhait - lors de la soumission d'opinions (calcul non exploité) Ce montant depend de 2 propriétés: 'priceminister.suggested_price.number_of_months' indique le nombre de mois sur lequel on va calculé la transaction moyenne (valeur par defaut 6 mois) 'priceminister.suggested_price.min_count' indique le nombre minimum de transactions pour calculer une moyenne (valeur par defaut 3) SI le nbre de transactions effectuées sur les 'priceminister.suggested_price.number_of_months' mois est superieur à 'priceminister.suggested_price.min_count' ALORS mAvgSalePrice = moyenne des transactions sur les x derniers mois SINON SI le nbre de transactions effectuées est superieur à priceminister.suggested_price.min_count ALORS mAvgSalePrice = moyenne des transactions SINON mAvgSalePrice = moyenne des transactions Pourrait-on avoir les mêmes informations pour le prix de vente conseillé? Ce calcul se fait en plusieurs etapes Prix de vente conseillé (suggested_price): 1) on tient compte du meilleur prix Ce montant depend de la propriété: 'priceminister.suggested_price.reduction_ratio_best_price' (valeur par defaut à.9) SI le produit a un meilleur prix (best_price) ALORS { suggested_price_1 = ratio_best_price * best_price SI suggested_price_1 > 0.5*list_price ALORS suggested_price_1 = 0.5*list_price 2) on tient compte du montant de la transaction moyenne observée depuis x mois calcul de mAvgSalePrice (different de l'explication précédente) Ce montant depend de 2 propriétés: 'priceminister.suggested_price.number_of_months' indique le nombre de mois sur lequel on va calculé la transaction moyenne (valeur par defaut 6 mois) J'appelle cette propriété nbMonth 'priceminister.suggested_price.min_count' indique le nombre minimum de transactions pour calculer une moyenne (valeur par defaut 3) 'priceminister.suggested_price.reduction_ratio_avg_sale_price' (valeur par defaut 0.95) J'appelle cette propriété ratio_2 // calcul de mAvgSalePrice SI le nbre de transactions effectuées sur les 'nbMonths' mois est superieur à 'min_count' ALORS mAvgSalePrice = moyenne des transactions sur les x derniers mois SINON SI le nbre total de transactions effectuées est superieur à priceminister.suggested_price.min_count ALORS mAvgSalePrice = moyenne des transactions SI mAvgSalePrice IS NOT NULL ALORS suggested_price_2 = ratio_2 * mAvgSalePrice // calcul de suggested_price SI suggested_price_1 IS NULL || suggested_price_2 < suggested_price_1 ALORS suggested_price = suggested_price_2 3) on tient compte des souhaits sur ce produit SI suggested_price IS NULL ALORS suggested_price = la valeur moyenne des souhaits 4) test du montant de suggested_price SI suggested_price < prix_minimum ALORS suggested_price = prix_minimum En bref le "montant de la transaction moyenne observée depuis 6 mois" n'est pas stocké dans la base de données. Je donne donc les régles de calcul associées: Voici la requête effectuée: SELECT AVG(CASE WHEN creation_date > :date THEN toEuro(item_cost_price + item_fixed_commission_net + item_fixed_commission_tax + item_varia_commission_net + item_varia_commission_tax, currency_id) ELSE NULL END) AS average_recent, COUNT(CASE WHEN creation_date > :date THEN 1 ELSE NULL END) AS count_recent, AVG(toEuro(item_cost_price + item_fixed_commission_net + item_fixed_commission_tax + item_varia_commission_net + item_varia_commission_tax, currency_id)) AS average_global, COUNT(*) AS count_global FROM item WHERE (product_id = :x3) AND (itm_status_code = 40) la variable date etant SYSDATE - le nombre de mois fixé dans la propriété 'priceminister.suggested_price.number_of_months' la valeur moyenne sur les x derniers mois est: average_recent / count_recent cette valeur moyenne n'est prise en compte que si le nombre de transactions est superieure a la propriété 'priceminister.suggested_price.min_count' |
| Commentaire de Geneviève Beaujard [ 23/nov./07 10:34 ] |
| Cette demande de renseignement m'amene a poster le bug http://pricejira.lan/browse/APP-18650 |
| Commentaire de Geneviève Beaujard [ 26/nov./07 07:52 ] |
|
rectificatif: la valeur moyenne des transactions sur les x derniers mois est: average_recent cette valeur moyenne n'est prise en compte que si le nombre de transactions est superieure a la propriété 'priceminister.suggested_price.min_count' Il existe une valeur moyenne globale: average_global calcul de la valeur moyenne des souhaits pour un produit: 1) on effectue la requête suivante: VAR x1 NUMBER § EXEC :x1 := n° produit; SELECT MAX(creation_date) AS creation_date, COUNT(*) AS count, MIN(buy_price) AS min, MAX(buy_price) AS max, AVG(buy_price) AS average FROM wish WHERE (product_id = :x1) AND (wsh_type_code = 10) -- normal AND (wsh_status_code = 10) -- open 2) la valeur moyenne d'un souhait (calculée dans Pricer.java) est: SI (count > 4 && average != null) ALORS valeur_moyenne = (average * count - min - max) / (count - 2) |
[Suppression COB M6] Metatache
(APP-15115)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 15.0.0 |
| Type: | Sous-tâche | Priorité: | Mineur |
| Rapporteur: | Richard Dubois | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Projets PM archivés: | Maintenance 15.x.x |
| Commentaires |
| Commentaire de Agathe Remy [ 11/avr./07 16:19 ] |
|
Déjà traité! Agathe |
Informations complémentaires à intégrer dans le rapport "panier_coupon_article"
(DEC-395)
|
|
| Etat: | Fermé |
| Projet: | Reporting |
| Composants: | Executive |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | Samir Beghdadi |
| Résolution: | Corrigé | ||
| Estimation restante: | 2 heures | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | 2 heures | ||
[EXP-2481] BI : Le share NFS de titan sur junon ne fonctionne plus Création: 27/juil./06 16:52 Mise à jour: 25/juin/07 18:58 Résolue: 28/juil./06 09:56 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Bloquant |
| Rapporteur: | Agathe Remy | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Il semble que le share NFS de titan sur junon n'a pas été remonté suite au crash d'hier?! Merci:-) Agathe |
| Commentaires |
| Commentaire de Antoine Koener [ 28/juil./06 09:54 ] |
|
Ca refonctionne ? |
| Commentaire de Agathe Remy [ 28/juil./06 09:56 ] |
|
Tout est OK:-) Merci! |
[BIN-126] [Cobranding] Infobébé : Mettre en place le reporting su BI Création: 02/août/06 10:38 Mise à jour: 22/oct./07 10:08 Résolue: 22/oct./07 10:08 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Ghislain Gridel | Attribution: | Romain Czornomaz |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Agathe, il s'agit de mettre en place le reporting du co-branding Infobébé. Ce n'est apparemment pas un co-branding en tant que tel. Il comprend les catégories produits jouets et puériculture. J'ai besoin des données suivantes : - New Buyer - New seller - Purchases - Items - Captured cost price - Commission amount without shipping - VAT on commission without shipping Merci. Ghislain |
| Commentaires |
| Commentaire de Ariane Baldinger [ 03/août/06 11:40 ] |
| il y a eu erreur sur la personne ... |
| Commentaire de Ghislain Gridel [ 12/mars/07 10:46 ] |
|
Agathe, des nouvelles de ce JIRA ? |
| Commentaire de Agathe Remy [ 12/mars/07 11:33 ] |
|
Ghislain, Nous venons de mettre en place un grand nombre de rapports pour toi et il me semble que tu as d'autres demandes plus urgentes (ex : cobranding auto)... A quoi cela sert-il de mettre la pression sinon générer des tensions? Agathe |
| Commentaire de Agathe Remy [ 25/sept./07 14:07 ] |
|
Ghislain, Olivier nous a annoncé que nous allions abandonner le partenariat InfoBébé. Ainsi, il me semble que ce JIRA devient obsolète. Pourvons-nous le fermer? Merci. Agathe |
| Commentaire de Ghislain Gridel [ 15/oct./07 17:09 ] |
|
Bonjour, il faudrait aussi désactiver les rapports envoyés à Infobébé car ce partenriat n'est plus actif.. Merci. Ghislain |
| Commentaire de Agathe Remy [ 22/oct./07 10:08 ] |
| C'est fait. |
[BIN-209] BI Espagne / rapport complémentaire (seller debt) Création: 26/oct./06 17:14 Mise à jour: 14/sept./07 17:31 Résolue: 07/févr./07 11:53 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Executive |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Philippe Favrot | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ESP - Espagne
|
| Description |
|
Rapport à mettre en place sur la partie Espagne (non encore
listé à ce jour - sauf erreur de ma part) : rapport déterminant la dette
vendeur ce rapport existe pour la France : cf. Titan confid / executive / seller_debt avant de te lancer dans les développements parlons en 5 minutes pour bien valider que le rapport Titan est correct (je n'en suis pas persuadé). Philippe |
| Commentaires |
| Commentaire de Agathe Remy [ 31/oct./06 11:13 ] |
|
Les règles de gestion du rapport sont les suivantes : - transaction confirmée par le vendeur - date d'autorisation du panier strictement inférieure au mois considéré - date de paiement de la compensation supérieure ou égale au mois considéré ou pas de date de paiement de la compensation - transaction non abandonnée Les informations fournies sont les suivantes : - date d'autorisation du panier - identifiant du panier - identifiant de la transaction - statut de la transaction - prix de l'article (cost price) - commission nette sur article (fixe+variable) - TVA sur commission article - montant des frais de ports (cost price) - commission nette sur frais de port - TVA sur commission frais de port - date de paiement de la compensation - statut de la compensation |
| Commentaire de Philippe Favrot [ 08/nov./06 13:13 ] |
|
Agathe, merci pour ces précisions. je voudrais creuser avec toi les trois éléments suivants : "statut de la transaction" "date de paiement de la compensation" " statut de a compensation". A ta disposition Merci Philippe |
| Commentaire de Agathe Remy [ 29/nov./06 12:16 ] |
|
Je viens de regarder pour les statuts de compensation. Il n'en existe que 2! 10 : Compensation ouverte (Open, any item or claim can be added) 40 : Compensation fermée (Compensation closed, no more items can be added) Agathe |
[BIN-409] [Centralisation PMV] : Etude des impacts de la V19 sur les rapports BI Création: 13/févr./08 15:34 Mise à jour: 29/avr./08 17:31 Echéance: 29/févr./08 00:00 Résolue: 29/avr./08 17:26 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Executive |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Agathe Remy | Attribution: | Romain Czornomaz |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Romain, Pourrais-tu faire l'analyse des impacts possibles de l'activation des vendeurs en mode PLATINE sur les rapports PMV (financiers et marketing)? Merci. Agathe |
| Commentaires |
| Commentaire de Romain Czornomaz [ 03/mars/08 17:40 ] |
|
Agathe, Le document sur les impacts est à valider. Merci d'avance, Romain |
| Commentaire de Agathe Remy [ 12/mars/08 10:58 ] |
|
Dans le rapport TITAN des opérations de février, cf fichier
ci-joint, les opérations des 25 et 26 février liées à la migration
(onglet « Data (3) » surlignées en jaune - onglet « summary » surlignées
en orange) ont été générées dans « DEBIT_TRANSFER » et « DEBIT_CHECK ». La contrepartie de ces opérations se trouve au crédit dans « CREDIT_COMPENSATION ». (je pense qu'il s'agit des compensations par chèque et par virement antérieures à la migration) 25/2/2008 DEBIT_TRANSFER 69 044.74 25/2/2008 DEBIT_CHECK 4 871.14 26/2/2008 DEBIT_TRANSFER 390.60 La migration ne doit pas avoir d'impact dans les mouvements du PMV, ces opérations doivent donc être toutes constatées au crédit dans « CREDIT_COMPENSATION » Ou bien alors les constater (au débit comme au crédit) dans une nouvelle « cause » qui pourrait être par exemple « MIGRATION ...», elles seraient alors isolées des autres mouvements du PMV. Il faut donc effectuer une correction sur les opérations des 25 et 26 février concernées. Si ce n'est pas très clair et si tu as besoin de précisions, n'hésite pas à revenir vers moi. Claudie |
[EXP-4606] [BI Prod] : problème de plan d'exécution sur latone Création: 05/nov./08 16:42 Mise à jour: 23/mars/09 16:31 Résolue: 23/mars/09 16:31 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Agathe Remy | Attribution: | Ayoub Benseghir |
| Résolution: | Impossible à reproduire | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour Ayoub, Depuis hier, les plans d'exécution de nos requête sur latone ne correspondent plus du tout aux plans réels lors de l'exécution de la requête. De plus, j'ai un message : 'PLAN_TABLE' is old version As-tu une idée de ce qui se passe? Merci pour ton aide. Agathe |
| Commentaires |
| Commentaire de Ayoub Benseghir [ 27/nov./08 11:37 ] |
|
Le message 'PLAN_TABLE' is old version n'est pas grave. Pour les plans d'exécution ca vient peut être des profils qui étaient activés, avez-vous toujours le problème depuis que Patrick les a désactivés? |
| Commentaire de Ayoub Benseghir [ 09/déc./08 10:30 ] |
| Pouvez-vous me fournir une requête de test svp |
| Commentaire de Ayoub Benseghir [ 12/mars/09 15:40 ] |
| Est-ce que le problème est toujours d'actualité? |
[INF-206] [BI] : Besoin de powerpoint sur le poste de Julien GIRARDET Création: 18/nov./08 11:55 Mise à jour: 21/nov./08 10:45 Résolue: 21/nov./08 10:38 |
|
| Etat: | Résolu |
| Projet: | Infrastructure |
| Composants: | Micro |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Agathe Remy | Attribution: | Stéphane Eccli |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Bonjour Stéphane, Julien doit préparer une présentation PowerPoint pour Justin. Pourrais-tu lui installer PowerPoint? Merci. Agathe |
| Commentaires |
| Commentaire de Stéphane Eccli [ 21/nov./08 10:38 ] |
| ok |
| Commentaire de Julien Girardet [ 21/nov./08 10:45 ] |
| Merci Stéphane |
[EXP-4614] [Alimentation BI] : erreur quotidienne dans l'analyse de l'ODS Création: 13/nov./08 19:22 Mise à jour: 10/sept./09 14:52 |
|
| Etat: | Ouvert |
| Projet: | Exploitation |
| Composants: | Comptage |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Agathe Remy | Attribution: | Julien Girardet |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Suite à l'incident d'aujourd'hui, nous venons d'identifier une erreur quotidienne dans l'analyse du schéma ODS dans les fichiers : /appli/oracle/admin/DW/bdump/ *** SERVICE NAME:(DW) 2008-11-13 01:38:16.518 *** SESSION ID:(179.30746) 2008-11-13 01:38:16.518 *** 2008-11-13 01:38:16.518 ksedmp: internal or fatal error ORA-00600: internal error code, arguments: [rworupo.1], [4092], [4000], [], [], [], [], [] Current SQL statement for this session: select min(minbkt),maxbkt,substrb(dump(min(val),16,0,32),1,120) minval,substrb(dump(max(val),16,0,32),1,120) maxval,sum(rep) sumrep, sum(repsq) sumrepsq, max(rep) maxrep, count(*) bktndv, sum(case when rep=1 then 1 else 0 end) unqrep from (select val,min(bkt) minbkt, max(bkt) maxbkt, count(val) rep, count(val)*count(val) repsq from (select /*+ parallel(t,16) parallel_index(t,16) dbms_stats cursor_sharing_exact use_weak_name_resl dynamic_sampling(0) no_monitoring */substrb("SUBMITTER_COMMENT",1,32) val, ntile(254) over (order by nlssort(substrb("SUBMITTER_COMMENT",1,32),'NLS_SORT = binary')) bkt from "ODS"."PRODUCT" t where substrb("SUBMITTER_COMMENT",1,32) is not null) group by val) group by maxbkt order by maxbkt Pouvez-vous nous aider à la résoudre? Merci. Agathe |
| Commentaires |
| Commentaire de Agathe Remy [ 13/nov./08 19:24 ] |
|
Pour info, voici l'ordre d'analyse que nous lançons: dbms_stats.gather_schema_stats(Ownname=>'ODS',estimate_percent=>DBMS_STATS.AUTO_SAMPLE_SIZE,method_opt=>'FOR ALL COLUMNS SIZE AUTO',cascade=>DBMS_STATS.AUTO_CASCADE,granularity=>'ALL', options=>'GATHER AUTO'); A votre dispo. Agathe |
| Commentaire de Patrick Pereira [ 09/déc./08 11:34 ] |
|
Après plusieurs tests avec le gather_schema_stats, je ne parviens pas à éviter l'erreur. Je vous propose donc de remplacer l'appel à la procédure précédente par l'appel suivant, dans le cas d'ODS : begin for tab in (select table_name from all_tables at where owner='ODS' and table_name not in ( select table_name from all_external_tables ext where owner='ODS' and ext.table_name = at.table_name ) ) loop DBMS_STATS.GATHER_TABLE_STATS('ODS',tab.table_name,NULL, 1, FALSE, 'FOR ALL INDEXED COLUMNS', NULL, 'default', FALSE); for idx in (select index_name from all_indexes where owner='ODS' and table_name = tab.table_name ) loop DBMS_STATS.GATHER_INDEX_STATS ('ODS',idx.index_name,NULL,DBMS_STATS.AUTO_SAMPLE_SIZE,NULL,NULL,NULL,DBMS_STATS.DEFAULT_DEGREE, 'ALL', FALSE); end loop; end loop; end; / J'ai testé l'opération sur Latone. Elle a fonctionné sans problème en 1m50s. Qu'en pensez-vous ? |
| Commentaire de Patrick Pereira [ 13/janv./09 16:07 ] |
| Ou en sommes-nous ? |
| Commentaire de Agathe Remy [ 10/sept./09 14:52 ] |
| Si tu as du temps... |
[EXP-1735] Ralentissement apllication BI java à cause de l'antivirus Création: 07/avr./06 09:55 Mise à jour: 25/juin/07 18:57 Résolue: 07/avr./06 10:14 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Maintenance |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Mohamed Ezzouak | Attribution: | ZZ_Arnaud Baali |
| Résolution: | Corrigé | ||
| Estimation restante: | 15 minutes | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | 15 minutes | ||
| Description |
|
Bonjour, L'antivirus Kaspersky ralenti l'application Java de Business Objects pour les utilisateurs suivants : François Rousseau & Romain Gajac. Peux-tu désactiver le scan sur les applications Java pour éviter ce type de ralentissement. Merci. Mohamed Ezzouak |
| Commentaires |
| Commentaire de ZZ_Arnaud Baali [ 07/avr./06 10:14 ] |
| L'application Java a été iniorée sur les postes de tout le marketing |
[BIN-168] BI Finance : purchases summary by month Création: 10/oct./06 16:54 Mise à jour: 14/sept./07 17:21 Résolue: 01/déc./06 17:10 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Executive |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Critique |
| Rapporteur: | Agathe Remy | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | 4 heures | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | 4 heures | ||
| Pays: |
FRA - France
|
| Description |
|
Est il possible de compléter ce rapport des informations suivantes : 1 - le tableau tel qu'il est présenté ne permet pas de savoir, pendant les 5 / 6 premiers jours du mois (m+1), si les chiffres au titre du VA capturé et des commissions du mois m sont finaux où s'ils sont provisoires du fait de transactions potentiellement toujours dans un statut transitoire pendant ce laps de temps (en revanche le VA autorisé du mois m, donné par BO le 1ier jour du mois (m+1), doit être définitif et ne doit en principe plus varier). Il serait utilise d'indiquer dans un cadre sous le tableau de bord tel qu'il est présenté (voir 1ier onglet du fichier excel joint) les deux chiffres suivants : - montant des paniers annulés ; - montant des paniers en suspens. (de cette manière on saura lorsque le montant des paniers en suspens est à 0 que les chiffres de commissions et de VA capturé sont définitifs). 2 - Par ailleurs, j'ai un fichier excel dans lequel je saisis tous les jours le VA ressortant du BO que je compare par rapport au même mois de l'année précédente en cumul depuis le début du mois ; par ailleurs à l'aide de diverses règles de trois (en particulier pour tenir compte du fait que le VA du BO est toujours supérieur au VA autorisé réel) j'en déduis un VA autorisé et capturé pour l'ensemble du mois que je compare à l'objectif ; tout ceci est un peu long et doit pouvoir être automatisé avec BO dans la mesure ou les données sont disponibles dans BO. L'idéal serait de pouvoir créer un second onglet selon le format du fichier excel joint (onglet : daily authorized GMS). |
| Commentaires |
| Commentaire de Agathe Remy [ 11/oct./06 12:34 ] |
| en suspens = REQUESTED ou OBSERVATION |
| Commentaire de Philippe Favrot [ 11/oct./06 13:50 ] |
|
Oui Philippe |
| Commentaire de Agathe Remy [ 02/nov./06 14:52 ] |
|
Le point 1 a été mis en place : tu trouveras dans le tableau de bord deux nouvelles lignes : Cancelling amount Pending amount Agathe |
| Commentaire de Philippe Favrot [ 03/nov./06 09:03 ] |
|
c'est nickel merci Philippe |
[BIN-337] [Exploitation] : procédure d'arrêt / démarrage de la plate-forme BI Création: 30/mai/07 17:35 Mise à jour: 29/janv./08 17:52 Echéance: 08/juin/07 00:00 Résolue: 02/janv./08 11:23 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Stéphane Boulanger | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Procédure d'arrêt/démarrage des serveurs de production
suivants : TITAN / LATONE / TELLUS (j'en ai oublié peut être?) L'idée est de documenter l'arrêt / démarrage des différents composants de la plate-forme de production décisionnelle. Il faudra notamment retrouvé les points suivants : - pre-requis - contraintes (plages horaires et dates où l'on ne peux pas arrêter la plate-forme) - dépendances entre les différentes composantes - ordre d'arrêt / démarrage - commandes utilisées (avec le nom d'utilisateur habilité à faire ces opérations) Merci d'avance. |
| Commentaires |
| Commentaire de Agathe Remy [ 02/janv./08 11:23 ] |
|
cf les documents suivants dans le répertoire V:\Reporting\BusinessIntelligence\Exploitation: - Procédure d'exploitation de l'alimentation.doc - Désactivation de l'alimentation V2.doc - Exploitation BO production.doc Patrice, puis-je fremer la demande? Merci:-) Agathe |
[BIN-53] BI : Recall : New buyers after mailing Création: 17/mars/06 14:42 Mise à jour: 14/sept./07 16:58 Echéance: 17/mars/06 00:00 Résolue: 21/mars/06 10:54 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Bloquant |
| Rapporteur: | Agathe Remy | Attribution: | Samir Beghdadi |
| Résolution: | Corrigé | ||
| Estimation restante: | 45 minutes | ||
| Temps consacré: | 15 minutes | ||
| Estimation originale: | 1 heure | ||
| Description |
|
- Le résultat des colonnes "Purchases" et "Net merchandise sold" ets identique?! - La dernière colonne doit être "Net commission" et non "Shipping commission" - Remplacer les noms de colonne "Buyers" par "Buyers count" et "Purchases" par "Purchases count" (je sais, je reviens en arrière, mais l'erreur est humaine;-) - Faire tenir le rapport sur une page A4 en format rapport (la colonne "Shipping commission" passe sur une deuxième page). |
| Commentaires |
| Commentaire de Samir Beghdadi [ 17/mars/06 18:30 ] |
| C bon pour les trois rapports. |
[EXP-783] Mise en place d'une sauvegarde de LANSON pour BI Création: 05/janv./06 12:39 Mise à jour: 25/juin/07 18:55 Echéance: 12/janv./06 00:00 Résolue: 12/janv./06 12:05 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Sébastien Tournay | Attribution: | Pap Ndiaye |
| Résolution: | Corrigé | ||
| Estimation restante: | 0 minutes | ||
| Temps consacré: | 4 heures | ||
| Estimation originale: | 4 heures | ||
| Description |
|
Intégrer dans notre boucle de sauvegarde quotidienne la
sauvegarde des instances BOREP, OWREP et WKFREP de LANSON. Prévoir de
faire cela base fermée (à confirmer avec Edouard) pour prendre
l'ensemble des fichiers de données et les différents controls files.
S'assurer de la nécessité de prendre d'autres fichiers. voir s'il est possbile de mettre cela sur la même bande de sauvegarde au moment ou l'on passe déjà sur LANSON pour ramasser les fichiers systèmes archivés. |
[BIN-84] BI : Rapports à envoyer par email aux partenaires de tracking (CDE) Création: 09/mai/06 18:46 Mise à jour: 14/sept./07 17:00 Résolue: 15/mai/06 17:51 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | 4 heures | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | 4 heures | ||
| Description |
|
cf V:\Reporting\BusinessIntelligence\Lot 1\Specs\DSD\DSD_Marketing_partnership_11.doc
|
| Commentaires |
| Commentaire de Samir Beghdadi [ 10/mai/06 15:53 ] |
| Les rapports Appel à facture sur CA et Appel à facture sur volume d'affaires sont prêts pour la validation |
[cob La Redoute] Metatache
(APP-13755)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Cobrandings |
| Affecte la/les version(s): | 11.1.0 (La Redoute) |
| Version(s) corrigée(s): | 11.1.0 (La Redoute) |
| Type: | Sub-bug | Priorité: | Mineur |
| Rapporteur: | Ghislain Gridel | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Projets PM archivés: | COB La Redoute | ||||||||
| Commentaires |
| Commentaire de Ghislain Gridel [ 12/déc./06 10:10 ] |
|
Aathe, Pour Redoute, : Il faut un rapport "envoi partenaire". il est à envoyer à : dbenbass@redoute.fr Merci. Ghislain |
| Commentaire de Younès Charrière [ 12/déc./06 10:36 ] |
| C'est pour toi agathe :) |
[Cobrand Dauphiné Libéré]
(APP-15119)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Cobrandings |
| Affecte la/les version(s): | 14.0.0 |
| Version(s) corrigée(s): | 14.0.0 |
| Type: | Sub-bug | Priorité: | Majeur |
| Rapporteur: | Ghislain Gridel | Attribution: | Thomas Séglard |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM archivés: | COB Dauphiné Libéré |
| Commentaires |
| Commentaire de Ghislain Gridel [ 10/avr./07 16:01 ] |
|
Bonjour, le site http://www.ledauphine-bonnesaffaires.com/ est en ligne. Pouvez-vous activer les rapports dès dimanche prochain (15 avril) svp ? Destinataire : Fabrice.Canet@ledl.com et patrick.claret@ledl.com Merci |
| Commentaire de Agathe Remy [ 10/avr./07 19:23 ] |
|
Ghislain, peux-tu préciser le reporting à activer : old school ou type LRO? Merci:-) |
| Commentaire de Ghislain Gridel [ 11/avr./07 12:00 ] |
| type LRO merci |
| Commentaire de Thomas Séglard [ 11/avr./07 14:58 ] |
|
Ok. Rapport programmé toutes les semaines, au format PDF. @+ ThomaS |
| Commentaire de Ghislain Gridel [ 11/avr./07 15:28 ] |
| Impec. Merci. |
[APP-16480] BI : Ajouter une change_date sur la table USR_COUPON Création: 24/mai/07 18:32 Mise à jour: 20/nov./07 11:27 Résolue: 26/sept./07 10:49 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 18.0.0 |
| Type: | Amélioration | Priorité: | Critique |
| Rapporteur: | Agathe Remy | Attribution: | Renaud Dierickx |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
screenshot-1.jpg
|
| Pays: |
ALL - Tous
|
| Classif1: | DB |
| Classif2: | coupon |
| Projets PM archivés: | Maintenance 18.x.x |
| Description |
|
Bonjour, Nous venons de mettre en place des rapports sur l'utilisation des coupons, hors il n'y a pas de CHANGE_DATE sur la table USR_COUPON permettant de suivre les évolutions (par exemple de statut) de cette table. Comme elle contient plus d'1 millions de lignes, cela nous arrangerait de pouvoir l'alimenter incrémentalement et non de la recharger entièrement toutes les nuits. Merci:-) Agathe |
| Commentaires |
| Commentaire de Renaud Dierickx [ 26/sept./07 10:45 ] |
|
C'est fait... Pour voir cette date de modification, il faut aller sur l'écran coupon d'un utilisateur et pointer le curseur sur la date de création d'un coupon.... Voir screenshot-1 |
[Cobrand Nice Matin]
(APP-15110)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Cobrandings |
| Affecte la/les version(s): | 14.0.0 |
| Version(s) corrigée(s): | 14.0.0 |
| Type: | Sub-bug | Priorité: | Majeur |
| Rapporteur: | Ghislain Gridel | Attribution: | Thomas Séglard |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM archivés: | COB Nice Matin |
| Commentaires |
| Commentaire de Ghislain Gridel [ 10/avr./07 16:03 ] |
|
Bonjour, le site http://nicematin.priceminister.com/ est en ligne. Pouvez-vous activer les rapports dès dimanche (15 arvil), svp ? Destinataire : ftouraille@nicematin.fr Merci. Ghislain |
| Commentaire de Agathe Remy [ 10/avr./07 19:23 ] |
|
Ghislain, peux-tu préciser le reporting à activer : old school ou type LRO? Merci:-) |
| Commentaire de Ghislain Gridel [ 11/avr./07 12:01 ] |
| type LRO . Merci |
| Commentaire de Thomas Séglard [ 11/avr./07 14:58 ] |
|
Ok. Rapport programmé toutes les semaines de type LRO et au format PDF. @+ ThomaS |
| Commentaire de Ghislain Gridel [ 11/avr./07 16:45 ] |
| Impec. Merci. |
[APP-14753] BI : besoin d'ajouter une CHANGE_DATE sur USR_ADDRESS Création: 23/janv./07 11:38 Mise à jour: 25/juin/07 18:48 Résolue: 20/avr./07 15:55 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Base de données, Compte utilisateur |
| Affecte la/les version(s): | 11.3.1 |
| Version(s) corrigée(s): | 14.0.0 |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | Patrick Pereira |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Site: | Prod |
| Classif1: | DB |
| Projets PM archivés: | Maintenance 14.x.x |
| Description |
|
Bonjour, Je viens de me rendre compte que l'on pouvais modifier une adresse en Front ou en BackOffice. Or il n'existe aucun moyen de tracer ces modifications (pas de change date, ni d'évènement associé à cette action). Pour alimenter le DataWareHouse, je charge les données de manière incrémentale, à savoir j'insère les nouveaux enregistrements et je mets à jour ceux qui ont été modifiés en me basant sur la CHANGE_DATE. Or celle-ci n'existant pas sur USR_ADDRESS, je n'ai aucun moyen de savoir qu'un enregistrement a été modifié dans la base du site. Je ne peux donc pas assurer la cohérence des adresses du DataWareHouse avec celles du site. Serait-il possible d'ajouter une CHANGE_DATE sur USR_ADDRESS afin que je puisse récupérer ces modifications? Merci:-) Agathe |
| Commentaires |
| Commentaire de Olivier Bourgeois [ 15/févr./07 15:09 ] |
|
Ok, colonne ajoutée, script associé : V14_0_0_ |
| Commentaire de Agathe Remy [ 18/avr./07 17:24 ] |
|
Le CHANGE_DATE n'est pas en NOT NULL comme sur les autres tables. Est-ce normal? De plus, il n'a pas été inititlaisé... Merci:-) Agathe |
| Commentaire de Olivier Bourgeois [ 18/avr./07 18:24 ] |
| Ok j'ai relivré un script pour mettre à jour la colonne et passé la colonne not null |
| Commentaire de Quentin de Chivré [ 18/avr./07 18:31 ] |
| il faut 2 script, 1 pre deploy, et un post depoly, sinon tout va planter en prod !!! |
| Commentaire de Olivier Bourgeois [ 18/avr./07 18:55 ] |
| Oui je voulais dire : j'ai livré un script supplémentaire pour l'init (et non pas relivré le même avec l'init et le passage "not null" ajouté dedans). |
| Commentaire de Younès Charrière [ 20/avr./07 15:01 ] |
|
Peux tu passer les scripts stp Patrick ? Merci. |
| Commentaire de Patrick Pereira [ 20/avr./07 15:48 ] |
| C'est fait en Integ |
| Commentaire de Agathe Remy [ 20/avr./07 15:55 ] |
|
C'est OK pour moi. Agathe |
[APP-11940] [Pangora] Afficher le nom du marchand par le biais d'un infolien Création: 31/août/06 17:26 Mise à jour: 24/oct./07 12:21 Résolue: 05/sept./07 15:11 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Promo |
| Affecte la/les version(s): | 9.0.3 |
| Version(s) corrigée(s): | 17.0.0 |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Charles Decaux | Attribution: | Dispatcher (Dev-Réserve) |
| Résolution: | Aucune correction envisagée | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Site: | Prod |
| Projets PM: | *** STANDBY *** |
| Classif1: | PROMO |
| Classif2: | PROMO - Pangora - monétisation |
| Description |
|
Pour répondre aux demandes de la DGCCRF, il faut mettre un
infolien au moment où l'internaute passe sa souris sur le texte de
l'offre proposée par Pangora. Il ne faut pas le mettre quand
l'internaute passe sa souris sur l'image. Le texte à mettre est le suivant : "Voir l'offre de [Nom du Marchand]" Désolé je poste ce JIRA directement vers application car mon interlocuteur fonctionnel est en congés (BLY). Merci |
| Commentaires |
| Commentaire de Olivier Bourgeois [ 01/sept./06 12:40 ] |
|
Jérôme tu pourras me donner un mini-maquettage pour ça stp ? Il s'agit de trouver la bonne police (taille et fonderie), ainsi que les bonnes couleurs. J'imagine qu'il doit aussi y avoir des obligations légales sur la taille de la police - non Charles on ne pourra pas mettre le texte en taille 2 pixels blanc sur fond jaune :-) |
| Commentaire de Charles Decaux [ 01/sept./06 15:29 ] |
|
héhé :-) C'est sûr qu'il faut éviter de faire un infobulle avec une police énorme . Ma reco est donc de faire plutôt discret : l'infobulle ne sert qu'à répondre aux demandes de la DGCRRF. Mais nous on ne souhaite pas mettre en avant le nom du marchand. |
| Commentaire de Olivier Bourgeois [ 01/sept./06 15:52 ] |
|
En fait on a deux choix pour l'implémentation : - la version spartiate qui utilise l'attribut TITLE d'un lien ou d'un SPAN : http://www.ccim.be/ccim328/trucs/info01.htm Elle s'affiche avec un petit délai et est gerée par le navigateur à tous les niveaux (aucun contrôle de son aspect). Super simple à mettre en place. - la version Javascriptée paramétrable au niveau du rendu : http://www.ccim.be/ccim328/trucs/info06.html Mais qu'il va falloir adapter un poil pour FF |
| Commentaire de Charles Decaux [ 07/sept./06 12:01 ] |
|
Il me manque une validation pour effectivement ajouter l'infobulle. Donc mise en standby merci |
| Commentaire de Olivier Bourgeois [ 07/sept./06 14:13 ] |
| Ok pour le stand-by, je le déplace vers la 904 pour nettoyer la 903 de ses bugs |
| Commentaire de Olivier Bourgeois [ 29/sept./06 15:56 ] |
| Toujours en stand-by : procrastiné en V905 |
| Commentaire de Charles Decaux [ 16/août/07 14:58 ] |
| on peut fermer cette demande |
[APP-20132] BI : CHANGE_DATE antérieure à la CREATION_DATE Création: 04/avr./08 20:00 Mise à jour: 07/avr./08 15:24 |
|
| Etat: | Ouvert |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 19.3.2 |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Agathe Remy | Attribution: | Arnaud Forgues |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM: | *** RESERVE *** |
| Classif1: | BO |
| Classif2: | messagerie |
| Description |
|
Bonjour, Un enregistrement de la table USR_MESSAGE n'a pas été inséré aujourd'hui dans le DataWareHouse parce qu'il possède une CHANGE_DATE inférieure à sa CREATION_DATE. Voici son identifiant : 122522223 (c'est un bilan vendeur). Ce qui est vraiment étrange, c'est que cet enregistrement n'a pas été inséré dans l'alimentation du 04/04 alors que sa date de création est du 03/04?! Serait-il possible de savoir comment ces dates sont affectées? Merci. Agathe |
| Commentaires |
| Commentaire de Julien Girardet [ 07/avr./08 15:24 ] |
|
Bonjour, Pour information, deux nouveaux enregistrements de la table USR_MESSAGE n'ont pas été inséré aujourd'hui et samedi dans le DataWareHouse avec une CHANGE_DATE inférieure à la CREATION_DATE. Voici leurs identifiants : 122720546, 123082556 Julien. |
[EXP-2107] pourrait on avoir des stat webalizer pour bi.priceminister.com dans l'extranet JMH ? Création: 23/mai/06 11:15 Mise à jour: 08/août/07 19:42 Résolue: 08/août/07 19:42 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Justin Ziegler | Attribution: | Patrice Boulanger |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Commentaires |
| Commentaire de Sébastien Tournay [ 23/mai/06 16:21 ] |
| Je viens de faire la demande de MAI à Jet |
| Commentaire de Justin Ziegler [ 08/août/07 19:42 ] |
| on ferme ! |
[EXP-2871] BI : impossible de se connecter à tellus via l'utilitaire de déploiement BusinessObjects Création: 20/oct./06 16:30 Mise à jour: 25/juin/07 18:59 Résolue: 30/oct./06 15:27 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Troubleshooting |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Bloquant |
| Rapporteur: | Agathe Remy | Attribution: | Patrice Boulanger |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Patrice, Malgré le redémarrage de BusinessObjects hier soir, nous n'arrivons toujours plus à nous connecter à tellus via l'utilitaire de déploiement BusinessObjects. Cette connection se fait normalement via l'arkoon sur les ports 6400 et 6402. Nous ne pouvons donc plus passer aucune correction ou évolution en Production!!! Il est donc urgent de régler ce problème:-) Cela fonctionnait jusqu'au 18 otcobre 2006 inclus. Merci:-) Agathe |
| Commentaires |
| Commentaire de Patrice Boulanger [ 20/oct./06 16:59 ] |
| MAI-017379 ouverte chez JET pour vérifier les accès Arkoon. |
| Commentaire de Patrice Boulanger [ 27/oct./06 09:56 ] |
| Les flux ont été ouverts dans les deux sens. Merci de vérifier. |
| Commentaire de Patrice Boulanger [ 30/oct./06 15:27 ] |
| C'est résolu, je clos. |
[BIN-129] BI : ajout et alimentation du champ REGISTRATION_DATE dans TD_USER_ACCOUNT Création: 17/août/06 15:12 Mise à jour: 14/sept./07 17:18 Résolue: 04/sept./06 12:01 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Nouvelle fonctionnalité | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | 2 jours | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | 2 jours | ||
| Description |
|
Bonjour, Il s'agit d'ajouter un champ dans notre table TD_USER_ACCOUNT du DataMart : REGISTRATION_DATE - Faire un document de spécification - Mettre à jour la structure de la table dans PowerDesigner, puis dans la base de données. Il faut ensuite alimenter ce champ via OWB : -mettre en place l'initialisation de la table USR_EVENT dans ODS (créer la table dans ODS et développer le mapping FULL) -développer la mise à jour journalière de la table USR_EVENT dans ODS (developper le mapping DAILY) -développer l'alimentation de la colonne REGISTRATION_DATE dans TD_USER_ACCOUNT (développer les mappings FULL et DAILY) en fonction des règles de gestion définies précédemment dans les spécifications. Merci:-) Agathe |
| Commentaires |
| Commentaire de Agathe Remy [ 17/août/06 15:14 ] |
|
Voici le bilan d'une première étude menée par Cyrille: Analyse des événements de la table usr_event pour l'insertion de la date d'inscription réelle des utilisateurs. Les événements normaux : 80 : Création de compte via achat 90 : Création de compte via annonce 100 : Création de compte standard 220 : Mutation en utilisateur Requête ; select trunc (min(creation_date)) from usr_event where use_type_code in (80, 90,100,220) group by user_account_id Faire un min ou un max car certains utilisateurs peuvent avoir plusieurs de ces événements (exemple 100 et 220 : user_id 10844344) Mutations : Pour les personnes changeant de type d'utilisateur, il existe deux événements associés : 400 : Mutation en particulier 410 : Mutation en pro Question : Quelle date d'inscription devons-nous prendre, ça première date d'inscription ou ça date de mutation ? Cas particulier. Il existe un événement dont le code est 470, libellé « Jeu ET VOUS ». Certain des utilisateur sont considéré comme des particuliers alors qu'il ne sont pas passer par les statuts standard (voir début du mail), mais ils ont une notation dans le champ description : « inscrit ». Exemple : 2435472. Or certain ont le code 470 avec la notion inscrit + les codes de base exemple : 1496765 Question : Quelle date devons-nous récupérer ? Les contacts : Aucune date d'inscription ne sera récupérée pour les contacts. Cyrille |
| Commentaire de François Le Lay [ 04/sept./06 11:15 ] |
|
Modifié mappings full et daily sur ODS pour alimentation de
la table USR_EVENT. A présent on ne conserve plus que les événements de
type 80,90,100,220,400 et 410. On passe ainsi de 118 millions de lignes à
un peu moins de 3 millions de lignes pour le full. |
| Commentaire de François Le Lay [ 04/sept./06 11:56 ] |
|
Alimentation Full de USR_EVENT sur ODS et update FULL via
PL/SQL du champ REGISTRATION_DATE sur TD_USER_ACCOUNT achevés. On a donc 2852898 utilisateurs dont la date de registration est non nulle. |
| Commentaire de François Le Lay [ 04/sept./06 12:01 ] |
|
Les workflows Daily étant actifs et valides je considère la
mise en place de ce champ achevée. Le package PL/SQL ayant servi à
l'alimentation FULL du champ sur DTM est DTM.F_REG_DATE_USER_ACCOUNT |
[BIN-241] [BI] : def des rubriques sellers count et new sellers count Création: 08/déc./06 12:11 Mise à jour: 14/sept./07 17:33 Résolue: 16/mai/07 18:34 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Alexandra Viravaud | Attribution: | Samir Beghdadi |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Salut Mohamed, Dans le rapport incitation vente, que représentent les colonnes "Sellers count" et "New sellers count". S'agit-il dans le 1er cas des personnes qui ont un inventaire ou de celles qui ont fait au moins une 1ère vente effective ? Merci alex |
| Commentaires |
| Commentaire de Agathe Remy [ 14/mai/07 11:01 ] |
|
Samir, Peux-tu répondre à Alex? Merci:-) Agathe |
| Commentaire de Samir Beghdadi [ 14/mai/07 15:14 ] |
|
Salut, Alex Pour commencer malheureusement pour toi Mohamed ne peux pas t'aider pour les Indicateurs par contre pour un séjour au Maroc je pense qu'il peut faire quelque chose. Alors, dans le rapport "incitation vente" on a : Le "Sellers count" : c'est le nombre des users qui ont déposés au moins une annonce jusqu'à maintenant. Le "New sellers" : c'est le nombre des users qui ont déposés leurs première annonce dans la période choisie dans le rapport (la réponse à la question "select advert creation year") |
[EXP-3550] BI : incident dans la génération des flux MM entre 3h et 7h le 30/04/2007 Création: 02/mai/07 16:54 Mise à jour: 06/août/07 15:18 Résolue: 06/août/07 15:18 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Troubleshooting |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | Patrice Boulanger |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Le traitement journalier de génération des flux 1000Mercis a duré 3h au lieu de 10mn?! Depuis, c'est revenu à la normale... En investiguant, nous nous sommes aperçus que c'étaient les scripts d'initialisation (init_file.sh) et de finalisation (finalize.sh) des fichiers qui duraient en moyenne 300 secondes pour juste ouvrir une fifo et écrire une ligne?!!! Pouvez-vous trouver ce qui s'est passé? Vous trouverez les scripts exécutés dans les répertoire /home/oracle/owb_outgoing de latone. Merci:-) Agathe |
| Commentaires |
| Commentaire de Justin Ziegler [ 06/août/07 14:36 ] |
|
Agathe, peut on fermer ce jira ? Est ce que le pb est résolu ? |
| Commentaire de Agathe Remy [ 06/août/07 15:18 ] |
|
En effet, cet incident a été réglé : je ne me souviens plus
très bien du pourquoi et du comment, mais c'était une histoire de
saturation de disque en écriture... Agathe |
[BIN-387] [Vehicle/Affiliation] : données pas à jour sur les rapport BI Affiliation Auto Création: 05/nov./07 11:53 Mise à jour: 16/nov./07 14:38 Résolue: 09/nov./07 16:13 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Lorenzo Nuccio | Attribution: | Romain Czornomaz |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Hello, comme vu ensemble. le dernier rapport que j'ai sorti sur les dépots d'annonce auto identifie des annonces déposées comme "non valide". Il faudrait donc voir d'où vient le problème pour pouvoir générer le rapport avec des données à jour. Merci |
| Commentaires |
| Commentaire de Romain Czornomaz [ 09/nov./07 16:13 ] |
|
Lorenzo, Il y avait un bug dans la mise à jour de la date de publication. J'ai modifié l'alimentation des données d'annonces auto et refait une initialisation des données. Vérifie sur ton rapport d'affiliation si les chiffres sont de nouveau corrects afin que je puisse fermer la demande. Bonne journée, Romain |
| Commentaire de Romain Czornomaz [ 16/nov./07 14:38 ] |
|
Lorenzo, Je ferme la demande suite à ta validation. Romain |
[BIN-512] [Droits d'accès BI] : demande d'accès aux rapports Wish pour l'utilisateur UR Technique Création: 06/nov./08 17:10 Mise à jour: 24/nov./08 16:22 Résolue: 06/nov./08 18:42 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Emeric Teil | Attribution: | Julien Girardet |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Pourriez-vous ouvrir le répertoire "Wish" à l'utilisateur "UR Technique" ?
|
| Commentaires |
| Commentaire de Agathe Remy [ 06/nov./08 18:17 ] |
|
A toi de jouer! Merci:-) |
| Commentaire de Julien Girardet [ 06/nov./08 18:42 ] |
|
Emeric, Le repertoire Wish est dispo avec le user UR Technique Amuse toi bien ;) Julien. |
[BIN-156] BI : prise en compte de l'évoluation de USR_SUBSCRIPTION avec la V9.0.3 Création: 19/sept./06 14:56 Mise à jour: 14/sept./07 17:20 Résolue: 10/oct./06 18:37 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Bug & Improvement |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | 1 jour | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | 1 jour | ||
| Pays: |
FRA - France
|
| Description |
|
Modification de l'alimentation du Datawarehouse et prise en compte des nouvelles données dans l'univers
|
[BIN-341] ouvrir les droits d'accès du rapport BI nb propects 2 (OM) Création: 06/juin/07 11:59 Mise à jour: 14/sept./07 18:04 Résolue: 11/juin/07 11:03 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Alexandra Viravaud | Attribution: | Samir Beghdadi |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Salut, dans le cadre du calcul de l'incentive MM, j'ai besoin de connaitre chaque mois le nb de comptes hors viral. Il me faut pour cela utiliser le rapport d'Olivier "nb prospects 2". Pour le moment, je peux accéder à ce rapport mais je ne peux pas le faire tourner en choissant la période qui m'intéresse pour les données. Pouvez-vous élargir les droits sur ce rapport ? Merci Alexandra |
| Commentaires |
| Commentaire de Samir Beghdadi [ 11/juin/07 11:03 ] |
|
D'aprés Alexandra c'est réglé. Merci |
[EXP-1573] BI : problème de connexion à http://latone.lan:5500/em/ Création: 21/mars/06 10:39 Mise à jour: 25/juin/07 18:57 Résolue: 22/mars/06 16:49 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Agathe Remy | Attribution: | Jérémie Bennejean |
| Résolution: | Corrigé | ||
| Estimation restante: | 0 minutes | ||
| Temps consacré: | 35 minutes | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Bonjour, Il nous est impossible de se connecter ce matin à l'adresse suivante : http://latone.lan:5500/em/ Y aurait-il un problème avec l'Arkoon? Merci:-) Agathe |
| Commentaires |
| Commentaire de Sébastien Tournay [ 21/mars/06 16:27 ] |
|
On avait effectivement un problème au niveau du FortiGate.
On avait constaté cela sur d'autres URL. Jérémie, tu peux nous confirmer
que c'est rentré dans l'ordre. Je voudrais également comprendre l'origine du problème. Il semblerait que cela soit lié à la modification d'une régle. Qui, quoi, comment ? |
| Commentaire de Jérémie Bennejean [ 21/mars/06 18:10 ] |
|
Depuis la fin de matinée l'accès à http://latone.lan:5500/em/ est possible. Cela est donc rentré dans l'ordre. L'origine du problème viens effectivement de la modification d'un paramétre d'une nos règles. La règle en question concerne wan2 qui dit que tout ce qui est en provenance du réseau 192.168.1.0/24 ( via internal) et qui en direction de wan2 est authorisé. ( sur un le plan on comprends mieux) L'option NAT doit être décocher ( sinon passage en @ de type 192.168.2.X, ce qui a été le cas ... ) et donc le routeur 9 tel n'acceptais pas les connections sur cette plage d'adresse. Maintenant reste à déterminer qui à modifier cette règle. Une premiere recherche dans les logs n'a rien retourné. Par ailleurs il n'y a pas de logs spécifiques aux connections sur le fortigate ( même en mode administration) ... ce qui rend les recherches totalement floues. |
[BIN-535] [CRM achat] : création de filtres sous BI dans les univers USER ACCOUNT et PURCHASE Création: 02/janv./09 14:40 Mise à jour: 18/nov./10 18:07 |
|
| Etat: | Ouvert |
| Projet: | Business Intelligence |
| Composants: | CRM |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Thomas Beylot | Attribution: | Julien Girardet |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Hello comme vu avec Dalila, j'aimerais créer un nouveau filtre dans l'univers user account qui me permettrait de sortir le nombre de nouveaux clients qui auraient fait leur premier achat dans les 45 jours suivant leur inscription en sélectionnant un pool de nouveaux clients par leur date d'arrivée dans la base. En effet ça me permettra d'affiner les projections budgétaires faite sur la campagne "Inscrits non acheteurs" mais aussi de voir si les diverses actions entreprises permettent d'augmenter le taux de transfo des inscrits non acheteurs. De plus je souhaiterais créer (ou alors il existe mais je ne l'ai pas trouvé) une autre dimension sur l'univers Item. En effet je souhaiterais pouvoir disposer de la note attribué à un produit par l'acheteur suite à son acte d'achat sur PM. Aujourd'hui j'ai l'impression que cette data n'est disponible que sous la forme d'une note attribué à un vendeur (en somme et en moyenne) ? à votre dispo pour plus de précisions, thomas |
| Commentaires |
| Commentaire de Dalila Belkebir [ 02/janv./09 18:14 ] |
|
Bonjour Thomas, La dimension " Item seller score " existe déjà dans l'univers ITEM. Tu la trouveras dans la classe ITEM (32 ème dimension) puisque une note est attribuée sur chaque item d'un panier. Pour ton autre demande, peux-tu nous dire si ton besoin est ponctuel (j'ai oublié de te le demander)? Si c'est le cas je te propose de te faire une extraction comme pour les autres études MKT. Sinon, nous regarderons quel est le meilleur filtre à créer. Cordialement, Dalila. |
| Commentaire de Thomas Beylot [ 05/févr./09 10:20 ] |
|
hello je regarde le coup du "item seller score" asap. pour mon autre demande elle est n'est pas ponctuelle non. Il s'agit de vérifier de façon régulière l'évolution du nb d'acheteurs / inscrits 45j car on a mis en place des mails auto pour améliorer cette transfo (par exemple). thomas |
[BIN-688] [Jeu vendeur] Intégrer à BI la donnée d'inscription d'un PriceMember au jeu vendeur Création: 03/sept./10 11:07 Mise à jour: 21/déc./10 10:21 Résolue: 20/déc./10 16:15 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Nouvelle fonctionnalité | Priorité: | Majeur |
| Rapporteur: | Fabrice Feugas | Attribution: | Julien Girardet |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Commentaires |
| Commentaire de Fabrice Feugas [ 03/sept./10 11:08 ] |
| Le lien vers le wiki (en cours de construction) : http://pricewiki.lan/Wiki.jsp?page=Jeu%20vendeur |
| Commentaire de Fabrice Feugas [ 26/oct./10 14:46 ] |
| URL obsolète, voici la nouvelle : http://pricewiki.lan/Wiki.jsp?page=JeuVendeur2010 |
| Commentaire de Julien Girardet [ 20/déc./10 16:15 ] |
|
Livré le 09/12/10 :
=> Univers USER ACCOUNT (classe Seller), ITEM (classe Seller account), ADVERT (classe User Account) : - Is seller game player ? : booléen indiquant si le PriceMember est inscrit au jeu vendeur - Seller game subscription date : date d'inscription au jeu vendeur - Seller game subscription month : mois d'inscription au jeu vendeur - Seller game player : filtre sélectionnant les PriceMembers inscrit au jeu vendeur - Select seller game subscription date : filtre pour sélectionner une date d'inscription au jeu vendeur - Select seller game subscription date period : filtre pour sélectionner une période de date d'inscription au jeu vendeur - Select seller game subscription month : filtre pour sélectionner un mois d'inscription au jeu vendeur - Select seller game subscription month period : filtre pour sélectionner une période de mois d'inscription au jeu vendeur Je ferme donc le JIRA. |
| Commentaire de Fabrice Feugas [ 21/déc./10 10:21 ] |
| Merci. |
[APP-15803] BI : Ajout des champs CREATION_DATE et CHANGE_DATE sur PRD_ATTRIBUTE Création: 03/avr./07 18:41 Mise à jour: 02/août/07 11:43 Résolue: 01/août/07 15:55 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 13.2.2 |
| Version(s) corrigée(s): | 16.0.0 |
| Type: | Nouvelle fonctionnalité | Priorité: | Critique |
| Rapporteur: | Agathe Remy | Attribution: | Mostafa Diane |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Classif1: | TECH |
| Projets PM archivés: | Maintenance 16.x.x |
| Description |
|
Bonjour, Afin de pouvoir mettre en place le reporting Voiture, nous avons besoin de récupérer en incrémental des attributs. Pour éviter de surcharger la base OLTP, pouvez-vous créer les champs CREATION_DATE et CHANGE_DATE sur PRD_ATTRIBUTE avec les indexs adéquats? Merci:-) Agathe |
| Commentaires |
| Commentaire de Nicolas Chauveau [ 04/mai/07 10:47 ] |
|
Le change date est il impacté par - a modif du lien produit / attribut - la modification de la valeur de l'attribut |
| Commentaire de Martin Sudmann [ 15/juin/07 09:53 ] |
|
1/ OK pour maintenir les dates sur changement de la table prd_attribute, NOK pour répercuter les changements de prd_attribute_value sur prd_attribute (mais après discussion avec Agathe, ce n'est pas nécessaire) 2/ Agathe, peux-tu mettre ta requête dans ce jira pour voir quel index il te faut ? |
| Commentaire de Agathe Remy [ 15/juin/07 10:41 ] |
|
Voici la requête : SELECT * FROM PRD_ATTRIBUTE WHERE CHANGE_DATE>=TRUNC(sysdate-1) AND INOUTGRP1.CREATION_DATE<TRUNC(sysdate) ; Cordialement, Agathe |
| Commentaire de Martin Sudmann [ 15/juin/07 15:04 ] |
| le remplissage des dates dans les attributs étant trop lourd pour la V15 (SBP !), décalage en V16 |
| Commentaire de Martin Sudmann [ 11/juil./07 14:24 ] |
| à traiter ensemble avec VID |
| Commentaire de Mostafa Diane [ 17/juil./07 11:06 ] |
| Désormais les deux colonnes existent et sont gérés par l'appli. J'ai également crée deux indexes sur les deux colonnes |
| Commentaire de Manuel Sadok [ 01/août/07 14:30 ] |
|
Problème de trigger lors d'une mise à jour d'attribut en BO 2007-08-01 14:18:34,501 INFO [P-Processor8] :velocitycoupon - >>> POST http://bo.pm.lan/referential_back!action=attributeu...&namekey=PMA0001501&prdattributeid=1260926113&productid=53362865&valuekey=PMK0000215&x=33&y=16 ... 2007-08-01 14:18:34,534 WARN [P-Processor8] :velocitycoupon - SQL Error: 4098, SQLState: S1000 2007-08-01 14:18:34,534 ERROR [P-Processor8] :velocitycoupon - [Oracle] #17 ORA-04098: trigger 'PRODUCT_1.TRG_SORT_ATTRIBUTE2' is invalid and failed re-validation 2007-08-01 14:18:34,534 ERROR [P-Processor8] :velocitycoupon - Could not synchronize database state with session org.hibernate.exception.GenericJDBCException: could not insert: [com.babelstore.stock.entity.PrdAttribute] at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:91) at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:79) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2077) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2426) at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:51) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:243) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:227) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:140) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:296) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:877) at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:201) at org.jboss.ejb3.entity.InjectedEntityManager.flush(InjectedEntityManager.java:122) at com.babelstore.stock.service.ProductManagerBean.flush(ProductManagerBean.java:1066) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:109) at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:32) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:113) at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:138) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:61) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:39) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:63) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:32) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:91) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) |
| Commentaire de Mostafa Diane [ 01/août/07 15:55 ] |
| le trigger TRG_SORT_ATTRIBUTE2 a été droppé par Patrick. refait les tests :) |
[APP-19155] BI : suppression d'une annonce de recrutement sur le site www.PriceMinister.com Création: 14/janv./08 14:45 Mise à jour: 21/janv./08 17:13 Résolue: 18/janv./08 16:41 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aide en ligne, Infoglue |
| Affecte la/les version(s): | 18.1.3 |
| Version(s) corrigée(s): | 18.1.3 |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | Steven Harel |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM: | *** A PLANIFIER *** |
| Description |
|
Bonjour, Serait-il possible de supprimer l'annonce de recrutement suivante : Stagiaire alternance ciblage Emailing Merci:-) Agathe |
| Commentaires |
| Commentaire de Steven Harel [ 17/janv./08 08:41 ] |
| inactivé dans infoglue |
| Commentaire de Christophe Garcia [ 18/janv./08 14:40 ] |
| Ariane, c'est parti en PROD ce truc ? |
| Commentaire de Ariane Baldinger [ 18/janv./08 14:56 ] |
|
Non. Je fais l'export / import aujourd'hui pour mise en Prod début semaine prochaine. |
[APP-7691] BI : problème d'affectation de la valeur de creation_date dans USR_COUPON pour les coupons de parrainage Création: 02/mars/06 10:56 Mise à jour: 25/juin/07 18:35 Résolue: 10/mars/06 08:13 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Coupons |
| Affecte la/les version(s): | 8.1.2 |
| Version(s) corrigée(s): | 8.1.2 |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Agathe Remy | Attribution: | Geneviève Beaujard |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Site: | Prod |
| Description |
|
Bonjour, Après discussion avec Quentin, il ne semble pas pertinent que la date de création des enregistrements des coupons CORLEONE soit affectée à la start_date. Il est donc envisageable de l'affecter avec la date de création de l'enregistrement (comme pour les autres coupons), ce qui nous permettrait d'alimenter le Datawarehouse sans recharger tous les jours la table USR_COUPON en entier. Voici donc l'object de ce JIRA : 1- Faire une étude des impacts éventuels de cette modification (i.e. voir si cette creation_date est utilisée pour calculer autre chose...) 2- Si les risques de régression de l'application ne sont pas trop grands, effectuer cette correction pour la version 8.1.2. Merci:-) Je suis à ta disposition pour toute question. Agathe |
| Commentaires |
| Commentaire de Geneviève Beaujard [ 02/mars/06 13:01 ] |
|
Seule la creation des coupons dont l'assignation est CouponStrategy.ASSIGNEMENT_USER se fait au moment de l'utilisation du coupon. Par exemple un coupon CORLEONE est crée lors du premier achat d'un filleul ET il est tout a fait normal que creation_date = start_date, dans ce cas la il s'agit d'une attribution. Pour agathe il faudrait creer une autre colonne 'date d'utilisation' que l'on renseignerai lors de l'utilisation. J'attends un feu vert pour savoir si c'est une bonne voie. |
| Commentaire de Geneviève Beaujard [ 03/mars/06 15:37 ] |
|
Les coupons qui sont créés un certain jour avec une date de creation qui est inferieur a la date du jour sont des coupons créés suite à la capture d'un panier si le panier a expiré ou si certains articles du panier annulés par le vendeur entrainent l'annulation du coupon. Danc se cas le coupon utilisé est detruit (ucp_status_code = 60), MAIS un nouveau coupon est créé avec toutes les infos de précedent coupon (dont creation_date). Pour ta solution il faudrait faire une modification dans l'EJBGenerator pour que le methode copyCouponInfo de UsrCouponEntityBean ne recopie pas creation_date et que ce soit bien le jboss qui mette la creation date (balise <audit>), je cree un bug dans ce sens: http://pricejira.lan/browse/APP-7716 extrait de advertbusiness-jbosscmp-jdbc.xml dans generated/advert <audit> <created-time> <field-name>creationDateValue</field-name> </created-time> <updated-time> <field-name>changeDateValue</field-name> </updated-time> </audit> |
| Commentaire de Judd OSullivan [ 08/mars/06 18:58 ] |
|
Fabrice va mettre à jour le generater des INFO ( |
| Commentaire de Geneviève Beaujard [ 09/mars/06 14:55 ] |
| Ok, mais il faudra nettoyer le CouponBusinessBean apres résolution du bug app-7116. |
| Commentaire de Patrick Condevaux [ 15/mars/06 17:18 ] |
| ok verifie avec genevieve |
[BIN-170] BI Finance : rapports Purchase by card type et Purchase by payment type Création: 11/oct./06 12:31 Mise à jour: 14/sept./07 17:21 Résolue: 30/oct./06 18:34 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Executive |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Critique |
| Rapporteur: | Agathe Remy | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | 2 heures | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | 2 heures | ||
| Pays: |
FRA - France
|
| Description |
|
- Modifier l'invite par mois en une invite par jour - vérifier le montant coupon qui est toujours égal à 0??? |
| Commentaires |
| Commentaire de Agathe Remy [ 11/oct./06 13:07 ] |
|
Le montant coupon a été corrigé et l'invite modifiée. Peux-tu me valider les rapports? Merci. Agathe |
[IMP-4736] Mise à jour des stocks > le pro est en -2 tant que les stocks ne sont pas à jour > il s'agît juste d'importer l'export BI avec les quantités > coco457 Création: 26/nov./09 14:51 Mise à jour: 01/déc./09 10:43 Résolue: 01/déc./09 10:43 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Support entrant |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Isabelle Weisbecker | Attribution: | Frédéric Nahum |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
coco457_Advert listing by login.xls
|
| Pays: |
FRA - France
|
| Login: | coco457 |
| Séparateur: | N/A |
| Type de traitement: |
Mise à jour/création annonces avec mise à jour/création produits (écrasement)
|
| Commentaires |
| Commentaire de Frédéric Nahum [ 01/déc./09 10:19 ] |
| j'ai soumis le fichier pour les maj de quantité |
| Commentaire de Frédéric Nahum [ 01/déc./09 10:43 ] |
| c'est fait |
[BCK-24] [EP] [Tech] Refaire le nouveau cycle de vie / schéma BDD et les renvoyer aux DBA / BI Création: 18/août/10 08:05 Mise à jour: 22/sept./10 18:17 Résolue: 30/août/10 16:13 |
|
| Etat: | Fermé |
| Projet: | Backlog Projets |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Renaud Dierickx | Attribution: | Damien Dorizy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Projets PM: | Espace personnalisé |
| Commentaires |
| Commentaire de Damien Dorizy [ 30/août/10 15:56 ] |
| C'est dans le Wiki : http://pricewiki.lan/Wiki.jsp?page=Impacts%20BDD%20CTN-U#section-Impacts+BDD+CTN-U-D_C3_A9tailEspacePerso |
[IMP-7780] Création format import rapport BI "Advert listing by login " + import des annonces > frenchstyle Création: 06/janv./11 12:21 Mise à jour: 19/janv./11 10:43 Résolue: 19/janv./11 10:43 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Demande commerciale |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Isabelle Weisbecker | Attribution: | Jérome Marianne |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
extraction annonces 06.01.2011.csv
|
| Pays: |
FRA - France
|
| Login: | frenchstyle |
| Modèle: | Advert listing by login |
| Séparateur: | Point-virgule (;) |
| Type de traitement: |
Mise à jour/création annonces avec mise à jour/création produits (écrasement)
|
| Commentaires |
| Commentaire de Habib-Sylvain Gourguet [ 10/janv./11 15:19 ] |
|
Bonjour,
Pour compléter la demande : le vendeur "frenchstyle" a vu ses annonces supprimées suite à une erreur en BO d'un opérateur SAV. Suite à cette erreur (qui nous est imputable), le vendeur harcèle le standard, le Service commercial et le Back Office d'appels téléphoniques. Merci de faire au mieux pour traiter en priorité cette demande. |
| Commentaire de Habib-Sylvain Gourguet [ 14/janv./11 16:39 ] |
|
Re,
Peut-on avoir plus d'informations quant au délai envisagé pour traiter cette demande, svp ? Ce vendeur PRO attend depuis maintenant près de 10 jours que PriceMinister répare son erreur, qui l'empêche de vendre sur notre site. |
| Commentaire de Jérome Marianne [ 18/janv./11 18:34 ] |
|
Format et profil import paramétrés.
Fichier soumis en création annonce avec recherche par ID produit. |
| Commentaire de Jérome Marianne [ 19/janv./11 10:43 ] |
| Les annonces sont en ligne. |
[IMP-7918] Le pro veut baisser ses prix en masse mais ne passe pas par les imports > passer l'extraction BI > magicprix Création: 27/janv./11 11:02 Mise à jour: 31/janv./11 15:57 Résolue: 31/janv./11 15:57 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Demande commerciale |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Isabelle Weisbecker | Attribution: | Esteban Rios |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Advert listing by login_magicprix_27.01.2011.csv
|
| Pays: |
FRA - France
|
| Login: | magicprix |
| Modèle: | extraction BI |
| Séparateur: | Point-virgule (;) |
| Type de traitement: |
Mise à jour/création annonces avec mise à jour/création produits (écrasement)
|
| Commentaires |
| Commentaire de Esteban Rios [ 31/janv./11 12:06 ] |
|
le fichier sera traité et MAJ annonce et pas Mise à
jour/création annonces avec mise à jour/création produits (écrasement)
car nous allons seulement mettre à jour les prix dans les annonces.
Merci de mettre à jour le jira.
(traitement convenu avec Isabelle Weisbecker par telephone) |
| Commentaire de Esteban Rios [ 31/janv./11 14:55 ] |
|
Fichier en cours de traitement :
http://bo.priceminister.com/datafile_back?action=advfilesearch&file_id=11611037&login=magicprix+&process_code=&status=&use_proc_date=false&start_date=&end_date=&order=&x=0&y=0 |
| Commentaire de Esteban Rios [ 31/janv./11 15:47 ] |
|
Demande traitée.
|
[EXP-590] Mettre en place les alertes minitord sur lanson Création: 16/déc./05 12:20 Mise à jour: 25/juin/07 18:55 Résolue: 18/janv./06 19:10 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Nouvelle fonctionnalité | Priorité: | Majeur |
| Rapporteur: | Edouard Laurent | Attribution: | Xiaoming Du |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Il faudrait mettre en place des alertes minitord, ces
alertes sont en rapport uniquement avec la plateforme BI (agathe) a ta dispo pour en parler |
| Commentaires |
| Commentaire de Sébastien Tournay [ 19/déc./05 18:01 ] |
| Bien définir un profil métier type BI que nous allons mettre en place. L'idée ensuite et de pousser ce profil sur la prod au même titre que nous avons un profil APACHE, JBOSS et BDD. |
| Commentaire de Xiaoming Du [ 18/janv./06 19:10 ] |
|
BI sera installé sur pommery. http://pricejira.lan/browse/EXP-786 |
[IMP-2994] extraction stock alphalibris Création: 12/déc./08 11:01 Mise à jour: 30/oct./09 15:43 Résolue: 12/déc./08 15:12 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Anne Korchia | Attribution: | Fotigui Tangara |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Login: | alphalibris |
| Séparateur: | Tabulation |
| Type de traitement: |
Mise à jour/création annonces avec création produits (écrasement)
|
| Description |
|
je n'arrive pas à extraire le stock d' alphalibris sur bi
pourriez vous le faire pour moi car il faut que je fasse la mise à jour
de son stock
|
| Commentaires |
| Commentaire de Fotigui Tangara [ 12/déc./08 15:12 ] |
| Nous ne disposons plus d'outils pour l'extraction de stock. Pour cela adressez-vous à l'équipe BI (Agathe). |
"Erreur - non disponible" dans les "Problèmes Q&A Produits"
(APP-29492)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 68.0.2 |
| Type: | Sub-bug | Priorité: | Mineur |
| Rapporteur: | Renaud Dierickx | Attribution: | Ayoub Benseghir |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Projets PM: | *** RESERVE *** |
| Description |
|
Le script a été créé en dev. Il faut le lancer en integ : V:\Database\V68_0_2\integ !!!!!!!!!!!! Attention, en prod il faudra garder les logs pour le BI !!!!!!!!!!!! |
| Commentaires |
| Commentaire de Ayoub Benseghir [ 10/mai/10 11:01 ] |
|
1 seule ligne en integ france: Update entity_post_relation_id n°44011 set entity_id = 92219457 rien en ES/UK. J'envoi en PROD? |
| Commentaire de Cédric Goldovsky [ 10/mai/10 11:16 ] |
|
en prod 40 questions concernées en 24H la semaine dernière Cela signifie qu'en théorie, on doit en avoir 160 concernées à cette heure. Tu peux le passer en PROD pour régler le problème mais n'oublie pas qu'il faudra le repasser en POST DEPLOY afin de corriger le delta. enfin, après passage en prod, pourras tu coller ici tous les updates réalisés (pour le BI) Merci |
| Commentaire de Renaud Dierickx [ 11/mai/10 15:49 ] |
|
Les logs de prod : 11/05/2010-09:42 -------------------------------------------------------------------- Execution du script V68_0_2_ -------------------------------------------------------------------- === Start 11/05/2010 09:42:54 ======== Connecté. Update entity_post_relation_id n°87511 set entity_id = 76014366 Update entity_post_relation_id n°87518 set entity_id = 50837583 Update entity_post_relation_id n°87487 set entity_id = 75933832 Update entity_post_relation_id n°87500 set entity_id = 81422259 Update entity_post_relation_id n°87554 set entity_id = 50022497 Update entity_post_relation_id n°87556 set entity_id = 97133816 Update entity_post_relation_id n°87559 set entity_id = 69679642 Update entity_post_relation_id n°87526 set entity_id = 53409377 Update entity_post_relation_id n°87535 set entity_id = 92617167 Update entity_post_relation_id n°87537 set entity_id = 16800345 Update entity_post_relation_id n°87539 set entity_id = 98903267 Update entity_post_relation_id n°87653 set entity_id = 52413378 Update entity_post_relation_id n°87612 set entity_id = 63393080 Update entity_post_relation_id n°87571 set entity_id = 9872781 Update entity_post_relation_id n°87573 set entity_id = 88076275 Update entity_post_relation_id n°87577 set entity_id = 57031924 Update entity_post_relation_id n°87568 set entity_id = 93227686 Update entity_post_relation_id n°87621 set entity_id = 46829509 Update entity_post_relation_id n°87623 set entity_id = 17293981 Update entity_post_relation_id n°87632 set entity_id = 84826049 Update entity_post_relation_id n°87643 set entity_id = 534522 Update entity_post_relation_id n°87586 set entity_id = 47234320 Update entity_post_relation_id n°87589 set entity_id = 5808303 Update entity_post_relation_id n°87663 set entity_id = 85611891 Update entity_post_relation_id n°87671 set entity_id = 54335497 Update entity_post_relation_id n°87676 set entity_id = 101284720 Update entity_post_relation_id n°87617 set entity_id = 58806025 Update entity_post_relation_id n°87682 set entity_id = 82285498 Update entity_post_relation_id n°87684 set entity_id = 58671788 Update entity_post_relation_id n°87686 set entity_id = 82015380 Update entity_post_relation_id n°87703 set entity_id = 2922348 Update entity_post_relation_id n°87708 set entity_id = 99346094 Update entity_post_relation_id n°87710 set entity_id = 3660139 Update entity_post_relation_id n°87680 set entity_id = 88681359 Update entity_post_relation_id n°87722 set entity_id = 57149797 Update entity_post_relation_id n°87727 set entity_id = 90621344 Update entity_post_relation_id n°87717 set entity_id = 394039 Update entity_post_relation_id n°87734 set entity_id = 57716530 Update entity_post_relation_id n°87739 set entity_id = 59311709 Update entity_post_relation_id n°87783 set entity_id = 57663448 Update entity_post_relation_id n°87891 set entity_id = 52012839 Update entity_post_relation_id n°87893 set entity_id = 7022711 Update entity_post_relation_id n°87812 set entity_id = 51866031 Update entity_post_relation_id n°87816 set entity_id = 934315 Update entity_post_relation_id n°87827 set entity_id = 85209508 Update entity_post_relation_id n°87831 set entity_id = 10976395 Update entity_post_relation_id n°87984 set entity_id = 73277696 Update entity_post_relation_id n°87955 set entity_id = 53375532 Update entity_post_relation_id n°87841 set entity_id = 92426141 Update entity_post_relation_id n°87850 set entity_id = 92076098 Update entity_post_relation_id n°87874 set entity_id = 83457058 Update entity_post_relation_id n°87881 set entity_id = 91647698 Update entity_post_relation_id n°87886 set entity_id = 58506466 Update entity_post_relation_id n°87902 set entity_id = 54897365 Update entity_post_relation_id n°87973 set entity_id = 89651854 Update entity_post_relation_id n°87913 set entity_id = 55109017 Update entity_post_relation_id n°87916 set entity_id = 586498 Update entity_post_relation_id n°87919 set entity_id = 99264738 Update entity_post_relation_id n°87947 set entity_id = 81116767 Update entity_post_relation_id n°87923 set entity_id = 17407394 Update entity_post_relation_id n°87933 set entity_id = 3778134 Update entity_post_relation_id n°87964 set entity_id = 73885572 Update entity_post_relation_id n°87966 set entity_id = 46508981 Update entity_post_relation_id n°88004 set entity_id = 60755744 Update entity_post_relation_id n°88012 set entity_id = 18581576 Update entity_post_relation_id n°88016 set entity_id = 6409638 Update entity_post_relation_id n°88051 set entity_id = 1796364 Update entity_post_relation_id n°88032 set entity_id = 53985790 Update entity_post_relation_id n°88034 set entity_id = 81877587 Update entity_post_relation_id n°87986 set entity_id = 72450133 Update entity_post_relation_id n°88008 set entity_id = 51445607 Update entity_post_relation_id n°88062 set entity_id = 143387 Update entity_post_relation_id n°87978 set entity_id = 85106066 Update entity_post_relation_id n°88071 set entity_id = 83792072 Update entity_post_relation_id n°88076 set entity_id = 91726653 Update entity_post_relation_id n°88102 set entity_id = 18053686 Update entity_post_relation_id n°88109 set entity_id = 76158835 Update entity_post_relation_id n°88112 set entity_id = 99503154 Update entity_post_relation_id n°88135 set entity_id = 53462530 Update entity_post_relation_id n°88139 set entity_id = 59062629 Update entity_post_relation_id n°88143 set entity_id = 48472894 Update entity_post_relation_id n°88145 set entity_id = 76880135 Update entity_post_relation_id n°88147 set entity_id = 81275963 Update entity_post_relation_id n°88149 set entity_id = 46551688 Update entity_post_relation_id n°88155 set entity_id = 98646599 Update entity_post_relation_id n°88159 set entity_id = 63642863 Update entity_post_relation_id n°88163 set entity_id = 70677679 Update entity_post_relation_id n°88165 set entity_id = 85100166 Update entity_post_relation_id n°88175 set entity_id = 80446378 Update entity_post_relation_id n°88177 set entity_id = 69761350 Update entity_post_relation_id n°88179 set entity_id = 69761350 Update entity_post_relation_id n°88251 set entity_id = 69761350 Update entity_post_relation_id n°88187 set entity_id = 4416503 Update entity_post_relation_id n°88191 set entity_id = 61985127 Update entity_post_relation_id n°88212 set entity_id = 17454840 Update entity_post_relation_id n°88216 set entity_id = 94262304 Update entity_post_relation_id n°88224 set entity_id = 88243675 Update entity_post_relation_id n°88241 set entity_id = 89209751 Update entity_post_relation_id n°88243 set entity_id = 98170897 Update entity_post_relation_id n°88246 set entity_id = 1199513 Update entity_post_relation_id n°88253 set entity_id = 69761350 Update entity_post_relation_id n°88255 set entity_id = 428610 Update entity_post_relation_id n°88261 set entity_id = 69761350 Update entity_post_relation_id n°88275 set entity_id = 5038732 Update entity_post_relation_id n°88283 set entity_id = 48078300 Update entity_post_relation_id n°88292 set entity_id = 2368264 Update entity_post_relation_id n°88303 set entity_id = 48670384 Update entity_post_relation_id n°88305 set entity_id = 228165 Update entity_post_relation_id n°88307 set entity_id = 323464 Update entity_post_relation_id n°88310 set entity_id = 851207 Update entity_post_relation_id n°88311 set entity_id = 98610292 Update entity_post_relation_id n°88313 set entity_id = 69365465 Update entity_post_relation_id n°88323 set entity_id = 99267616 Update entity_post_relation_id n°88337 set entity_id = 53600584 Update entity_post_relation_id n°88341 set entity_id = 48979481 Update entity_post_relation_id n°88343 set entity_id = 1089309 Update entity_post_relation_id n°88381 set entity_id = 78872082 Update entity_post_relation_id n°88391 set entity_id = 75971399 Update entity_post_relation_id n°88395 set entity_id = 99462207 Update entity_post_relation_id n°88376 set entity_id = 48534998 Update entity_post_relation_id n°88433 set entity_id = 92985061 Update entity_post_relation_id n°88553 set entity_id = 90478779 Update entity_post_relation_id n°88454 set entity_id = 1133619 Update entity_post_relation_id n°88514 set entity_id = 10518673 Update entity_post_relation_id n°88516 set entity_id = 3288433 Update entity_post_relation_id n°88473 set entity_id = 2539984 Update entity_post_relation_id n°88486 set entity_id = 3322381 Update entity_post_relation_id n°88491 set entity_id = 81057949 Update entity_post_relation_id n°88493 set entity_id = 98609798 Update entity_post_relation_id n°88500 set entity_id = 299974 Update entity_post_relation_id n°88742 set entity_id = 63403019 Update entity_post_relation_id n°88504 set entity_id = 46813090 Update entity_post_relation_id n°88459 set entity_id = 90412352 Update entity_post_relation_id n°88542 set entity_id = 1049219 Update entity_post_relation_id n°88548 set entity_id = 5270600 Update entity_post_relation_id n°88521 set entity_id = 16485617 Update entity_post_relation_id n°88524 set entity_id = 93614954 Update entity_post_relation_id n°88535 set entity_id = 99768248 Update entity_post_relation_id n°88537 set entity_id = 18538045 Update entity_post_relation_id n°88581 set entity_id = 89661850 Update entity_post_relation_id n°88593 set entity_id = 62830737 Update entity_post_relation_id n°88622 set entity_id = 2496922 Update entity_post_relation_id n°88662 set entity_id = 60691145 Update entity_post_relation_id n°88612 set entity_id = 77402243 Update entity_post_relation_id n°88618 set entity_id = 531381 Update entity_post_relation_id n°88635 set entity_id = 5353098 Update entity_post_relation_id n°88671 set entity_id = 97117812 Update entity_post_relation_id n°88674 set entity_id = 71291068 Update entity_post_relation_id n°88695 set entity_id = 68578472 Update entity_post_relation_id n°88712 set entity_id = 77534795 Update entity_post_relation_id n°88715 set entity_id = 1004211 Update entity_post_relation_id n°88718 set entity_id = 1180272 Update entity_post_relation_id n°88723 set entity_id = 3213560 Update entity_post_relation_id n°88610 set entity_id = 52792823 Update entity_post_relation_id n°88771 set entity_id = 96573975 Update entity_post_relation_id n°89023 set entity_id = 504963 Update entity_post_relation_id n°88783 set entity_id = 5865116 Update entity_post_relation_id n°88798 set entity_id = 81167912 Update entity_post_relation_id n°88803 set entity_id = 50698169 Update entity_post_relation_id n°88807 set entity_id = 101406448 Update entity_post_relation_id n°88825 set entity_id = 48810491 Update entity_post_relation_id n°88831 set entity_id = 81504546 Update entity_post_relation_id n°88833 set entity_id = 1308430 Update entity_post_relation_id n°88844 set entity_id = 94118132 Update entity_post_relation_id n°88854 set entity_id = 83096567 Update entity_post_relation_id n°88858 set entity_id = 5300208 Update entity_post_relation_id n°88861 set entity_id = 205202 Update entity_post_relation_id n°88865 set entity_id = 68048793 Update entity_post_relation_id n°88885 set entity_id = 49862535 Update entity_post_relation_id n°88888 set entity_id = 71079731 Update entity_post_relation_id n°88904 set entity_id = 61113754 Update entity_post_relation_id n°89051 set entity_id = 64410682 Update entity_post_relation_id n°88916 set entity_id = 83439860 Update entity_post_relation_id n°88941 set entity_id = 1135825 Update entity_post_relation_id n°88945 set entity_id = 82084561 Update entity_post_relation_id n°88962 set entity_id = 60415582 Update entity_post_relation_id n°88993 set entity_id = 49563561 Update entity_post_relation_id n°88973 set entity_id = 82571488 Update entity_post_relation_id n°88897 set entity_id = 57716540 Update entity_post_relation_id n°88954 set entity_id = 70819130 Update entity_post_relation_id n°88959 set entity_id = 3288996 Update entity_post_relation_id n°89012 set entity_id = 648747 Update entity_post_relation_id n°89007 set entity_id = 97296082 Update entity_post_relation_id n°89009 set entity_id = 5086011 Update entity_post_relation_id n°88827 set entity_id = 75203192 Update entity_post_relation_id n°89072 set entity_id = 57738297 Update entity_post_relation_id n°89035 set entity_id = 85100166 Update entity_post_relation_id n°89038 set entity_id = 48313271 Update entity_post_relation_id n°89062 set entity_id = 79569966 Update entity_post_relation_id n°89098 set entity_id = 73497060 190 Procédure PL/SQL terminée avec succès. Pas d'erreur. === Done 11/05/2010 09:42:59 ======== Ecoulé : 00 :00 :05.81 11/05/2010-09:42 -------------------------------------------------------------------- Execution du script V68_0_2_ -------------------------------------------------------------------- === Start 11/05/2010 09:43:00 ======== Connecté. Update entity_post_relation_id n°103202 set entity_id = 21571317 1 Procédure PL/SQL terminée avec succès. Pas d'erreur. === Done 11/05/2010 09:43:00 ======== Ecoulé : 00 :00 :00.29 11/05/2010-09:43 -------------------------------------------------------------------- Execution du script V68_0_2_ -------------------------------------------------------------------- === Start 11/05/2010 09:43:00 ======== Connecté. 0 Procédure PL/SQL terminée avec succès. Pas d'erreur. === Done 11/05/2010 09:43:00 ======== Ecoulé : 00 :00 :00.30 11/05/2010-09:43 Fin du script |
| Commentaire de Julien Girardet [ 12/mai/10 11:26 ] |
|
C'est ok pour nous (BI), script passé sur notre base. Merci. |
[BIN-566] [Partners] : Création d'un rapport pour Kelkoo Création: 04/mars/09 15:08 Mise à jour: 08/juin/09 15:08 Résolue: 03/juin/09 12:12 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Partners |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Ghislain Gridel | Attribution: | Geoffroy Vigneron |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
DMR - Appel à facture Kelkoo.docx
DMR - Appel à facture Kelkoo_1.1.docx
DMR - Appel à facture Kelkoo_1.2.docx
DMR+-+Appel+à+facture+Kelkoo_1.1.docx
screenshot-1.jpg
|
| Pays: |
FRA - France
|
| Description |
|
Salut, En marge du deal Kelkoo comparateur en marque blanche, il a été négocié un deal de visibilité sur la vente sur Kelkoo.fr. Il y aura un bloc en bas de toute les pages. Ci-joint un exemple de création. Leur rémunération sera la suivante : - 6 euros par nouveau membre actif priceminister --> rapport Xiti car membre actif est un e notion Xiti en first tracking - 5% de commission sur les ventes générées dans un délai de 30 jours suivant le clic de l'utilisateur sur Kelkoo. --> Rapport BI Il faudrait donc inclure dans ce rapport le Volume d'Affaire hors frais de port capturé en last tracking 30 jours. Idéalement il faudrait rajouter leur commission en calculant directement les 5%. Le code de tracking est le suivant 2232140. A votre dispo pour toute question. Ghislain |
| Commentaires |
| Commentaire de Agathe Remy [ 04/mars/09 19:56 ] |
|
Bonjour Ghislain, Si je comprends bien ta demande, il faudrait mettre en place un appel à facture pour le deal Kelkoo sur la vente. Pour cela, j'aurais besoin que tu me précises les points suivants : - Quand ce deal doit être mis en place sur le site ? - Quand doit-on leur envoyé leur 1er appel à facture? - Est-ce qu'un envoi le 5 de chaque mois (comme pour les autres partenaires de tracking) te conviendrait? - L'appel à facture se base-t-il sur un tracking ou un groupe de tracking? - Tu parles d'inclure un indicateur dans un rapport BI : de quel rapport parles-tu? Peux-tu nous donner son emplacement et son nom? - Tu parles d'un deal sur la vente. Peux-tu donc me confirmer que dans ce cas, la notion de last tracking 30 jours signifie "il s'est écoulé maximum 30j entre le dépôt du cookie et le dépôt de l'annonce par le vendeur"? (et pas "il s'est écoulé maximum 30j entre le dépôt du cookie et l'achat effectué par l'acheteur"). Si oui, as-tu bien conscience qu'une vente peut survenir plusieurs mois après le dépôt d'une annonce? - Avez-vous besoin d'un appel à facture pour la rémunération du deal comparateur en marque blanche? A ta dispo si tu as des questions! Agathe |
| Commentaire de Agathe Remy [ 09/mars/09 14:22 ] |
|
Bonjour Ghislain, Si cette demande est réellement majeure, il faudrait que tu répondes aux questions ci-dessus... Merci. Agathe |
| Commentaire de Ghislain Gridel [ 20/mars/09 16:23 ] |
|
Bonjour Agathe, j'attendais un retour de mon contact qui est en vacances... Ci-dessous les réponses à tes questions : Quand ce deal doit être mis en place sur le site ? --> il sera mis en place le 1er avril sur Kelkoo - Quand doit-on leur envoyé leur 1er appel à facture? --> Le 1er appel à facture devra être envoyé début mai. (par moi ou BI - a voir) - Est-ce qu'un envoi le 5 de chaque mois (comme pour les autres partenaires de tracking) te conviendrait? --> Oui, si on peut inclure la notion de nouveau membre actif dans BI. - L'appel à facture se base-t-il sur un tracking ou un groupe de tracking? --> L'appel à facture se base sur le groupe de tracking Kelkoo-Vente. - Tu parles d'inclure un indicateur dans un rapport BI : de quel rapport parles-tu? Peux-tu nous donner son emplacement et son nom? --> Je ne comprends pas. - Tu parles d'un deal sur la vente. Peux-tu donc me confirmer que dans ce cas, la notion de last tracking 30 jours signifie "il s'est écoulé maximum 30j entre le dépôt du cookie et le dépôt de l'annonce par le vendeur"? (et pas "il s'est écoulé maximum 30j entre le dépôt du cookie et l'achat effectué par l'acheteur"). Si oui, as-tu bien conscience qu'une vente peut survenir plusieurs mois après le dépôt d'une annonce? --> Après discussion, il s'agit bien du volume d'affaire achat capturé hors frais de port hors CBV, en last tracking 30 jours. (et non le VA généré par les vendeurs) - Avez-vous besoin d'un appel à facture pour la rémunération du deal comparateur en marque blanche? --> cette question concerne Benjamin. Mais dans ce cas c'est Kelkoo qui fera un appel à facture à PM (ils nous reversent un revenu) Par ailleurs, peut-être peut-on prendre toute l'info dans BI ? Voilà le contenu de l'appel à facture : tracking groupe | Volume d'affaire | Nouveaux membre actif | Revenus Kelkoo tracking groupe : Kelkoo vente Volume d'affaire ; volume d'affaire achat capturé hors frais de port hors CBV, en last tracking 30 jours Nouveau membre actif : un nouveau membre actif est un nouvel acheteur ou un nouveau vendeur Revenus Kelkoo : 6¿ par Nouveau membre actif +5% du VA A ta dispo ghislain |
| Commentaire de Ghislain Gridel [ 20/mars/09 16:45 ] |
|
il faut donc : - un appel à facture envoyé le 5 du mois - un reporting hebdo envoyé tous les lundis destinataire : njornet@yahoo-inc.com en copie : comparateur@priceminister.com Merci ! |
| Commentaire de Dalila Belkebir [ 16/avr./09 16:38 ] |
|
Ghislain, Nous sommes en cours de rédaction des spécifications et voici ce que nous venons de voir ensemble : - le VA capturé HT, hors CBV, hors frais de port - le tracking du panier à 30 jrs (comme pour Pangora) Il nous manque des précisions sur ce que tu considères comme un membre actif. Etant une notion XITI et comme vu avec toi, tu vas demander à Swan ce qui est précisément considéré comme membre actif (le but du jeu étant de ressortir les mêmes données que XITI afin de les comparer). Je te propose donc de mettre à disposition les spécifications dans le JIRA . Cette première version des spécifications ne comprendra pas la notion de membre actif que nous ajouterons dans une version ultérieure quand tu nous aura fourni les éléments nous permettant de le calculer. Ces spécifications seront disponibles d'ici 17h30 ce jour pour validation. Cela nous permettra d'avancer sur les développements du rapport et de te le mettre à disposition rapidement. A ta disposition pour en reparler. Cdlt, Dalila. |
| Commentaire de Cyril Tanneau [ 16/avr./09 16:50 ] |
|
Guislain, Voici les spécification concernant les rapports "Kelkoo - appel à facture ", pour les versions hebdo et mensuelles. En attente de ta validation, merci, Cyril |
| Commentaire de Ghislain Gridel [ 17/avr./09 09:54 ] |
|
SAlut, peut-on mettre le nombre de membres actifs directement dans BI ? et du coup l'insérer dans l'appel à facture avec le volume d'affaire ? et du coup calculer la rémunération total partenaire ? Peut-on avoir le détail par code de tracking ? Définition d' un membre actif : le membre est devenu actif. Il a effectué une première action : soit une vente effective, ou un premier achat. Ghislain |
| Commentaire de Ghislain Gridel [ 17/avr./09 10:03 ] |
| le membre actif est en first tracking |
| Commentaire de Cyril Tanneau [ 17/avr./09 10:25 ] |
|
Guislain, Dalila, Voici la nouvelle version de la spec incluant la rémunération pour les nouveaux membres actifs. merci :-) |
| Commentaire de Dalila Belkebir [ 17/avr./09 10:26 ] |
|
Ghislain, Nous avons pris en compte tes retours ce matin dans la nouvelle version des spécifications (v1.1) que nous venons d'associer au jIRA : - définition du membre actif - ajout des codes trackings dans le corps du tableau au lieu du groupe de tracking. Merci donc de nous les valider asap afin de débuter les développements. A ta disposition pour d'éventuels retours. cdlt, Dalila. |
| Commentaire de Ghislain Gridel [ 17/avr./09 10:42 ] |
| qq modifs rapides ci-jointes. a ta dispo |
| Commentaire de Cyril Tanneau [ 17/avr./09 11:34 ] |
|
Guislain, Dalila, les modifications ont été apportées à la spécification en fonction des remarques de Ghislain. La version finale de la spec est donc disponible à partir du lien : http://pricejira.lan/secure/attachment/31698/DMR+-+Appel+%E0+facture+Kelkoo_1.2.docx Merci, Cyril |
| Commentaire de Ghislain Gridel [ 17/avr./09 12:10 ] |
| ok pour moi. merci |
| Commentaire de Dalila Belkebir [ 05/mai/09 09:39 ] |
|
Bonjour Ghislain, Nous avons mis en production le rapport Kelkoo hier. A cause de limitations techniques, la version disponible ne comporte pas les informations relatives aux membres actifs. En effet, il s'agit d'une notion assez complexe à mettre en ¿uvre car elle implique la mise en place de processes d'alimentation et de dénormalisation. Ces processes là ne peuvent être mis en place dans le cadre d'un JIRA mais nécessitent un mini projet à prioriser avec Agathe. La planification des rapports hebdo et mensuel est mise en place. merci donc de tes retours pour validation. Cdlt, Dalila. |
| Commentaire de Ghislain Gridel [ 05/mai/09 11:07 ] |
| Merci Dalila. Odile planifiera ce projet avec Agathe. |
| Commentaire de Dalila Belkebir [ 06/mai/09 18:11 ] |
|
Ghislain, Juste une petite question : l'appel à facture doit être fourni au format excel ou bien pdf (impossible de le modifier par le partenaire)? Pour le moment il est fourni au format excel si cela ne te convient pas, il s'agit tout simplement de modifier le format dans la planification. Cdlt, Dalila. |
| Commentaire de Ghislain Gridel [ 12/mai/09 10:32 ] |
|
Bonjour, étant donné que l'appel à facture mensuel est incomplet (il manque les membres actifs), cela ne sert à rien de l'envoyer. Je l'ai fait moi-même à la main du coup. En revanche je me sers du montant du VA hors frais de port indiqué dans ce fichier. Pouvez-vous donc retirer les destinataires Kelkoo de l'appel à facture mensuel et laisser mon email svp ? Merci ! Ghislain |
| Commentaire de Dalila Belkebir [ 12/mai/09 11:38 ] |
|
Bonjour Ghislain, C'est fait. Cdlt, Dalila. |
| Commentaire de Agathe Remy [ 28/mai/09 17:12 ] |
|
Bonjour Ghislain, Dans les spécifications que tu as validé, un membre actif était défini comme : - Un nouvel acheteur, c'est-à-dire un PriceMember en first tracking ayant effectué son premier achat capturé au cours de la période étudiée OU - Un nouveau vendeur, c'est-à-dire un PriceMember en first tracking ayant effectué sa première vente capturée au cours de la période étudiée Hors il s'avère que suite à nos derniers échanges, il me semble que la règle de gestion correcte est: - Un nouvel acheteur, c'est-à-dire un PriceMember en first tracking ayant effectué son premier achat autorisé au cours de la période étudiée OU - Un nouveau vendeur, c'est-à-dire un PriceMember en first tracking ayant effectué sa première vente confirmée au cours de la période étudiée S'il te plait, peux-tu me confirmer cette nouvelle règle de gestion? Nous disposons dans le BI de toutes les données pré-calculées permettant d'implémenter cette dernière règle de gestion. Dans ce cas, nous n'aurons donc aucun problème à l'intégrer aux rapports Kelkoo. Merci. Agathe |
| Commentaire de Agathe Remy [ 28/mai/09 17:31 ] |
|
J'en profite également pour te demander de confirmer le modèle de rémunération. En effet, le contrat spécifie : 5% de commissions sur les ventes générées dont la traduction juridique est la suivante : VA capturé TTC, frais de ports inclus, hors CBV Hors, dans les spécifications de Kelkoo (et donc le rapport), nous avons la définition suivante : VA capturé HT, hors frais de port, hors CBV (modèle de rémunération de Nextag) S'il te plait, peux-tu nous indiquer quelle est la règle de gestion correcte? Merci. Agathe |
| Commentaire de Ghislain Gridel [ 28/mai/09 17:43 ] |
|
merci Agathe, dans le cadre du deal kelkoo, on souhaite les rémunérer si PM gagne de l'argent donc c'est forcément du capturé. En revanche sur la définition du membre actif, on peut la caler sur celle de Xiti, qui doit être de l'autorisé (à confirme pas Swan) |
| Commentaire de Ghislain Gridel [ 28/mai/09 18:13 ] |
|
voilà : Un nouvel acheteur, c'est-à-dire un PriceMember en first tracking ayant effectué son premier achat autorisé au cours de la période étudiée OU - Un nouveau vendeur, c'est-à-dire un PriceMember en first tracking ayant effectué sa première vente confirmée au cours de la période étudiée dans le contrat, on parle bien de VA capturé TTC, frais de ports inclus, hors CBV Merci |
| Commentaire de Agathe Remy [ 28/mai/09 18:29 ] |
|
Geoffroy, S'il te plait, peux-tu prendre en compte les corrections sur : - les nouveaux membres actifs - le calcul du VA ? Il s'agit de mettre à jour les spécifications, ainsi que les rapports hebdos et mensuels. Merci. Agathe |
| Commentaire de Geoffroy Vigneron [ 03/juin/09 12:12 ] |
|
Ghislain, Pourras - tu valider l'appel à facture mensuel qui sera généré le 05 juin 2009? Merci. Cordialement, Geoffroy |
| Commentaire de Ghislain Gridel [ 08/juin/09 15:01 ] |
| ok. merci. |
| Commentaire de Agathe Remy [ 08/juin/09 15:08 ] |
| Merci! |
[BIN-413] [Seller debt] : Réconcilier la dette vendeurs sur 2007/12 et 2008/01 Création: 18/févr./08 11:17 Mise à jour: 29/avr./08 17:33 Echéance: 22/févr./08 00:00 Résolue: 29/avr./08 17:26 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Finance |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Agathe Remy | Attribution: | Romain Czornomaz |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Ecarts sur la réconciliation de la dette vendeur sur décembre 2007 : - l'équipe BI doit investiguer ; => Retour prévu avant le 23/02/2008 - l'équipe Comptable doit faire la réconciliation sur janvier 2008 ; Voir s'il y a lien un lien avec le bug des compensations vendeurs exemptés de TVA?! |
| Commentaires |
| Commentaire de Romain Czornomaz [ 28/févr./08 11:16 ] |
|
La dette vendeur a été réconciliée de notre cote jusqu'à Janvier 2008 inclus. Dans les reste à faire, nous devons comparer nos résultats à ceux de Claudie. |
| Commentaire de Agathe Remy [ 12/mars/08 10:56 ] |
|
Il subsiste des écarts entre les données calculées par
l'équipe BI et l'équipe Finance. Pour le calcul du volume d'affaires,
nous nous basons sur des rapports différents. Nous devons investiguer pour comprendre d'où proviennent les écarts entre les rapports « payment by purchase » et « purchase summary by month ». Les écarts représentent 372 ¿ en 2007. |
| Commentaire de Romain Czornomaz [ 29/avr./08 17:33 ] |
|
La dette vendeur a été réconciliée jusqu'au 1 Mars 2008. Pour Philippe, il est nécessaire de passer sur les chantiers restants. Si des écarts significatifs sont découverts, la demande pourra être réouverte. Romain |
Déploiement Infoglue - lot PM-IG-0.1
(EXP-997)
|
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Installation |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | Sébastien Tournay | Attribution: | Ranto Andriambololona |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Faire la demande à JMH pour créer le nom
cms.priceminister.com. On peut utiliser la VIP '212.23.167.55' (utilisée
aussi pour bo et bi.priceminister.com)
|
| Commentaires |
| Commentaire de Ranto Andriambololona [ 24/janv./06 12:34 ] |
|
Je viens de faire la demande à JET pour l'ajout DNS et VIP >MEP-005198 >Bonjour, >Merci de mettre en place la nouvelle entrée cms.priceminister.com dans nos DNS >VIP >212.23.167.55 >RIPS >Dans /etc/hosts de >Phaeton >212.23.167.8 bo.priceminister.com intra.priceminister.com bi.priceminister.com cms.priceminister.com >Cupidon >212.23.167.33 bo.priceminister.com bi.priceminister.com cms.priceminister.com |
| Commentaire de Ranto Andriambololona [ 24/janv./06 14:39 ] |
| La demande a été traité par Jet, j'ai vérifié manuellement c'est OK |
| Commentaire de Sébastien Tournay [ 24/janv./06 17:27 ] |
|
En fait le nom plus adaptée serait 'eglue.priceminister.com'
peux tu faire la demande à JMH pour qu'il puisse faire le changement ? Merci d'avance Sébastien |
| Commentaire de Ranto Andriambololona [ 25/janv./06 11:01 ] |
| Demande effectuée et manip réalisée par JET |
[APP-32152] La propriété priceminister.product.redirection.prd_status_code_list est commentée en ES / UK Création: 08/déc./10 16:24 Mise à jour: 10/déc./10 16:40 Résolue: 09/déc./10 14:33 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Référencement |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 83.0.0 (VEN-F) |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Thierry Leforestier | Attribution: | Jean-Sébastien Franck |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
GBR - Royaume Uni, ESP - Espagne
|
| Site: | Prod |
| Projets PM: | *** A PLANIFIER *** |
| Navigateur: | Tous |
| Description |
|
La propriété est commentée ou vide en ES et UK :
priceminister.product.redirection.prd_status_code_list Merci de la reinseigner avec le prd_status_code 50 Est-ce qu'on peut traiter le status conflit par ce biais ? Merci ! |
| Commentaires |
| Commentaire de Jean-Sébastien Franck [ 09/déc./10 14:33 ] |
|
J'ai modifié la propriété en ES et UK, elle sera active en prod lors de la sortie de la VEN-F.
Le statut conflit peut également être géré par ce biais. Attention, en ce qui concerne les fusions de FP, il y a déjà des redirections qui sont faites mais on ne se base pas sur le statut du produit mais sur la valeur du champ target_product_id du produit. Si tu veux faire des redirections pour les produits fusionnés, il est donc inutile de modifier la propriété, c'est déjà géré. Pour que ce soit plus clair, voici les règles qui sont appliquées quand tu affiches une FP : 1) si le produit a un target_product_id (cas des fusions de FP), on fait une redirection 2) si le produit a un statut présent dans la liste priceminister.product.redirection.prd_status_code_list, on fait une redirection 3) les autres règles de redirection : checks urlname etc |
[BIN-405] [Espagne] Demande de Rapport : taux de réachat Espagne Création: 01/févr./08 12:33 Mise à jour: 23/mai/08 16:29 Résolue: 18/févr./08 17:23 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Charles Decaux | Attribution: | Florian Ambrosi |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Pays: |
ESP - Espagne
|
||||||||
| Description |
|
Bonjour, un indicateur important pour le marketing est le taux de réachat. Cette info est disponible sur la France grâce aux rapports Titan. Sur l'Espagne, nous n'avons pas cette info car pas de rapports Titan. Il faudrait donc mettre en place un rapport BI nous donnant : - le taux de réachat global site - le taux de réachat par tracking et groupe de tracking Merci et à votre dispo pour en parler Charles |
| Commentaires |
| Commentaire de Agathe Remy [ 05/févr./08 15:06 ] |
|
Charles, Peux-tu nous donner le chemin d'accès dans l'intranet du ou des rapports titan au(x)quel(s) tu fait allusion? Merci:-) Agathe |
| Commentaire de Charles Decaux [ 05/févr./08 17:03 ] |
|
http://intra.priceminister.com/stats/reports/confid/Big_Buyers/ |
| Commentaire de Agathe Remy [ 07/févr./08 12:26 ] |
|
Charles, Ce rapport peut être fait sous BI. En revanche, comme pour l'autre JIRA, le rapport auquel tu fais allusion ne possède aucune information de tracking ou groupe de tracking. S'agit-il donc d'une demande de nouveau rapport? Et si oui, pourrais-tu la spécifier de façon un peu plus précise? Je suis à ta dispo pour en discuter:-) Agathe |
| Commentaire de Charles Decaux [ 08/févr./08 09:41 ] |
|
Ok merci. Tant pis si je ne l'ai pas par tracking, je serait déjà content de l'avoir "global site". Veux-tu que je passe te voir pour que tu me montres les indicateurs à utiliser pour avoir ce rapport sous BI ? Merci |
| Commentaire de Agathe Remy [ 11/févr./08 18:40 ] |
|
Charles, D'après notre discussion, tu serai intéressé par le taux de réachat par first tracking. Peux-tu me le confirmer? De plus, veux-tu que nous considérions les achats autorisés ou capturés? Merci:-) Agathe |
| Commentaire de Florian Ambrosi [ 12/févr./08 15:53 ] |
|
Agathe, J'ai bien modifier les rapports avec tes modifications. Je fais un petit rappel car tout était fait par email auparavant. Les modifications demandées : - Renommer le rapport en « Purchase frequency by first tracking group » (modifier également le titre du rapport et le nom de l'onglet) - Ajouter le filtre « Captured purchase » et supprimer la condition « Captured purchase count >= 1) - Agrandir la largeur de la cellule de section - Ajouter le panier moyen (Avg purchase = Captured GMS/Captured purchase) - Renommer les en-têtes de colonne - Ajouter un total pas tracking (pied de tableau) Pour rappel, les rapports se situent dans la partie Développement/First Tracking, pour le premier et dans Développement/Purchase pour le second. Les specs se situent quand à elle dans "V:\Reporting\BusinessIntelligence\Evolutions\Purchase frequency". Florian |
| Commentaire de Florian Ambrosi [ 18/févr./08 17:23 ] |
|
Agathe Le rapport à valider. Merci. |
| Commentaire de Agathe Remy [ 21/févr./08 14:51 ] |
|
Charles, Les rapports suivants ont été livrés en Espagne : - "Purchase frequency by first tracking group" dans le répertoire Dossiers publics/Spain/First tracking - "Purchase frequency" dans le répertoire Dossiers publics/Spain/Purchase Peux-tu nous dire s'ils te conviennent? Surtout que certains les attendent en France... Merci:-) Agathe |
| Commentaire de Agathe Remy [ 28/févr./08 11:01 ] |
|
Charles, Peux-tu nous faire un retour sur ces rapports afin que nous puissions les livrer également en France? Merci. Agathe |
| Commentaire de Charles Decaux [ 05/mars/08 19:07 ] |
| Merci à vous, je valide les rapports |
| Commentaire de Agathe Remy [ 12/mars/08 11:50 ] |
|
A la demande d'Odile, nous avons renommé les rapports en "Buyers distribution by purchase count". Les 2 rapports ont également été déployés en France. |
[BIN-6] Installation serveur base de données Création: 12/déc./05 19:31 Mise à jour: 14/sept./07 16:55 Echéance: 30/déc./05 00:00 Résolue: 02/août/06 16:45 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Σ Estimation restante: | 1 heure, 30 minutes | Estimation restante: | Non spécifié |
| Σ Temps consacré: | 1 jour, 7 heures, 50 minutes | Temps consacré: | Non spécifié |
| Σ Estimation originale: | 2 jours | Estimation originale: | Non spécifié |
| Liens des demandes: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sous-tâches: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Installation de la partie Base de données pour le projet BI
|
[BIN-254] comptage des PMV avec de l'argent disponible Création: 26/déc./06 17:53 Mise à jour: 14/sept./07 17:33 Résolue: 19/janv./07 16:27 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Alexandra Viravaud | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Salut, j'ai récemment fait un comptage sur BI pour connaitre le nb de personnes ayant des PMV avec de l'argent dessus. Ce nb est inférieur à 7000, ce qui ne correspond pas à la réalité. Est-ce que vous pouvez jeter un oeil à ma requête pour voir si je n'ai pas fait une erreur (dossier Alexandra /PMV positifs ) ? Merci Alexandra |
| Commentaires |
| Commentaire de Alexandra Viravaud [ 02/janv./07 11:21 ] |
|
Hello ! Nous avons résolu le pb sur le comptage et nous arrivons à environ 70 000 personnes. Je souhaite maintenant ajouter la condition suivante : "la personne est abonnée" : - à au moins une newsletter (ht, culturelle, maison et loisir) et/ou - à la relance vieux acheteurs et/ou - à la relance acheteurs déçus Comment mettre en place sur BI la condition et/ou relative à l'abonnement ? Merci Alex |
[BIN-505] [Tracking] : Extraction des last tracking d'une sélection de paniers pour comparaison avec DI Création: 22/oct./08 17:59 Mise à jour: 24/nov./08 16:57 Résolue: 18/nov./08 18:25 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Agathe Remy | Attribution: | Dalila Belkebir |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
extraction panier tracking pour GGR le 30102008.xls
PURCHASE ID.xls
|
||||||||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Description |
|
Bonjour Agathe et Dalila, Je mène un étude sur les différences de trackings entre DI et BI. DI est l'outil de tracking de Nextedia, notre agence de liens sponsorisés, qui mesure aussi le ref nat. J'ai pris 2000 paniers au hasard sur la journée d'hier que j'ai transmis à Nextedia pour qu'ils me donneNt le tracking associés à ces paniers chez eux. J'aimerai moi aussi trouver les last tracking 30 jours de ces paniers chez nous. Comment faire ça rapidement ? Merci de votre retour Ghislain |
| Commentaires |
| Commentaire de Agathe Remy [ 22/oct./08 18:16 ] |
|
Bonjour Ghislain, S'il te plait, peux-tu nous préciser l'objectif de ton étude sur les différences entre DI et BI afin que nous puissions au mieux répondre à ta demande? Par exemple, ton objectif est-il d'évaluer combien de paniers ont des trackings différents sur un échantillon de 2000? Pour rappel, DI et BI n'affectent pas les trackings de la même manière au panier puisque DI n'écrase pas les trackings LS avec les trackings Marketing et inversement BI n'écrase pas les trackings Marketing ou LS par le réferencement naturel. Peux-tu également me confirmer que la demande consiste à te fournir la liste des last trackings 30 jours associés aux paniers listés dans le tableau Excel ci-joint? Enfin, peux-tu préciser le niveau d'urgence (pour quand en as-tu besoin? est-ce que Nextedia t'a fournit une date de livraison?) et de priorité de ta demande (Mineur, Majeur, etc...) en fonction de l'objectif business? Merci. Agathe |
| Commentaire de Ghislain Gridel [ 22/oct./08 18:48 ] |
|
Agarthe, suite à notre discussion : Objectif : évaluer combien de paniers ont des trackings différents sur un échantillon de 2000 paniers Demande: Fournir la liste des last trackings 30 jours associés aux paniers listés dans le tableau Excel ci-joint Niveau d'urgence : assez urgent. J'attends un retor de Nextedia à ce sujet Par ailleurs, il y aura aussi un lot 2 avec 2000 autres paneirs extraits de DI. Merci ! |
| Commentaire de Dalila Belkebir [ 30/oct./08 17:59 ] |
|
Ghislain, Voici l'extraction (en PJ) que j'ai réalisée à partir des ID paniers que tu as fournis. N'hésites pas à me faire tes retours. Cordialement, Dalila. |
| Commentaire de Ghislain Gridel [ 30/oct./08 18:05 ] |
| Merci. c'est impecable. Je te tiens au courant. |
| Commentaire de Agathe Remy [ 13/nov./08 18:33 ] |
|
Bonjour Agathe, Nous t'enverrons demain 5 échantillons de paniers tirés de Decisive Insight - 2000 paniers tirés de l'ensemble des canaux - 2000 paniers LS hors marques - 2000 paniers LS marque - 2000 paniers ref nat marque - 2000 paniers ref nat hors marque L'objectif sera de mesurer les écarts de chiffres entre DI et BI Pour chaque fichier nous comparerons : - id panier - date du panier - last tracking 30 jours - volume d'affaire - commission Penses-tu pouvoir revenir vers nous là-dessus demain dans la journée ? Nous attendons les fichiers de l'agence pour début de matinée D'avance merci Mathieu |
| Commentaire de Agathe Remy [ 13/nov./08 18:39 ] |
|
Mathieu, Le volume d'affaires et la commission que tu veux comparer sont-ils : - autorisé ou capturé ? - avec ou sans frais de port ? - avec ou sans TVA ? Merci de tes retours. Agathe |
| Commentaire de Odile Szabo [ 13/nov./08 19:02 ] |
|
Agathe, Les écarts de VA et com qu'on veut mesurer sont ceux que l'on prend habituellement dnas le rapport purchase tracking by month donc c'est de l'autorisé, hors frais de port et sans tva (c'est bien ça qu'on a dans purchase tracking by month?). cette demande est prioritaire devant les autres car les réponses sont essentielles pour nous aider à prendre la bonne décision sur la dedup ref nat et le pilotage des campagnes mots clés (idéalement si on a l'info pour notre dej du 20 avec Swan ça serait top!). bref, notre deadline est le 21/11. c'est jouable pour toi? dis moi si tu as un pb, merci odile |
| Commentaire de Dalila Belkebir [ 17/nov./08 18:11 ] |
|
Heu .... sauf erreur de ma part je ne vois pas les ID des paniers sur lesquels requêter .... Pouvez-vous SVP les attacher à la demande ? Cela me permettra de les générer maintenant. Merci. Dalila. |
| Commentaire de Dalila Belkebir [ 18/nov./08 18:25 ] |
|
Demande traitée dans le JIRA 520. Voir le fichier attaché au JIRA 520. Cordialement, Dalila. |
[BIN-550] [BACK-OFFICE] ajout dimensions précalculées? Création: 19/janv./09 11:39 Mise à jour: 16/févr./10 10:03 |
|
| Etat: | Ré-ouvert |
| Projet: | Business Intelligence |
| Composants: | BackOffice |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Cedric Favero | Attribution: | Julien Girardet |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
JIRA sous la forme d'une question. Qqch qui est disponible directement dans le BO mais qu'on est obligé de recalculer systematiquement dans le BI, c'est le taux de réclamation et le taux d'acceptation d'un vendeur. Serait-il possible d'avoir des dimensions prédéfinies dans l'univers ITEM? Un claim ratio: rapport entre les item capturés ayant une claim accepted et les autres Un acceptation ratio: rapport entre les items authorized et les items cancelled (seller_refused et seller_commit_timeout uniquement , pas les négo refusées) Merci. |
| Commentaires |
| Commentaire de Agathe Remy [ 19/janv./09 13:19 ] |
|
Bonjour Cédric, Nous pouvons en effet ajouter des indicateurs pré-définis pour ces ratios. Attention, comme ce sont des indicateurs, leur sens varie en fonction des dimensions sélectionnées dans le rapport (périmètre de l'analyse). Dans le BO, le périmètre de la fiche d'un vendeur est fixe, contrairement au BI où cela dépend des dimensions (axes d'analyse) sélectionnées. Ainsi, pour avoir le taux d'acceptation d'un vendeur, il ne faudra pas oublier de sélectionner l'identifiant du vendeur (ou son pseudo), sinon il te calculera le ratio par mois ou autre dimension sélectionnée... Autre remarque, le nb d'items capturés ayant une réclamation acceptée varie dans le temps puisqu'une réclamation peut être réouverte, même plusieurs années plus tard. Ayant déjà plusieurs JIRAs en cours, je planifierai la réalisation de ta demande à partir de la semaine prochaine. A ta dispo si tu as d'autres questions. Agathe |
| Commentaire de Cedric Favero [ 19/janv./09 14:49 ] |
|
çà me va. "Ainsi, pour avoir le taux d'acceptation d'un vendeur, il ne faudra pas oublier de sélectionner l'identifiant du vendeur " => ce sera toujours par rapport à un pseudo bien sur. "Autre remarque, le nb d'items capturés ayant une réclamation acceptée varie dans le temps puisqu'une réclamation peut être réouverte, même plusieurs années plus tard. " => comme en BO d'ailleurs :-) |
| Commentaire de Cedric Favero [ 19/janv./09 14:51 ] |
|
Par compte, apres reflexion,il me faudrait plutot un "Cancel
Ratio" qu'un "Acceptation Ratio" (meme chose à l'envers) (attention à n'inclure dans les cancelled que ceux refusés par le vendeur ou en time_out) Merci d'avance. |
| Commentaire de Dalila Belkebir [ 14/août/09 18:10 ] |
|
Habib, => Concernant le "Cancel ratio", on a créé l'indicateur "Cancellation rate" dans la classe Financial Indicators, car cette dimension peut s'appliquer à un seller mais aussi à un buyer. Cet indicateur permet de calculer le nombre d'articles annulés (hors négo) DIVISÉ PAR le nombre d'articles autorisés. => Concernant "rapport entre les item capturés ayant une claim accepted et les autres", on a créé l'indicateur Captured item claim rate dans la classe financial indicators. Il permet de calculer le nombre d'items avec une claim acceptée sur le nombre d'items capturés. Merci de ton retour pour validation. Dalila. |
| Commentaire de Dalila Belkebir [ 17/sept./09 15:33 ] |
|
Bonjour Habib, Peux-tu me faire un retour sur ce JIRA afin de le clôturer ? Merci de vérifier que les données calculées par les indicateurs sont bien correctes. Cdlt, Dalila. |
| Commentaire de Steven Harel [ 14/oct./09 14:46 ] |
|
désolé pour le retour tardif. le cancel ratio ne fonctionne pas. comme si on avait un ratio (cancelled/(cancelled + tous les autres)) avec "tous les autres" = 0. on a donc systématiquement des taux de 100% c'est quoi pour vous des articles "autorisés" ? chez nous c'est un statut temporaire de panier et pas d'article. pour moi, le ratio devrait être calculé ainsi : articles articles annulés/articles achetés avec : - articles annulés = cancelled avec juste les labels seller_refused et seller_commit_timeout - articles achetés = committed + closed + on hold + (cancelled (seller_refused et seller_commit_timeout)) |
| Commentaire de Cyril Tanneau [ 30/oct./09 10:14 ] |
|
Steven, Le taux d'annulation au niveau de l'article est calculé comme suit : 1-(nombre d'articles capturés hors négo/nombre d'articles autorisés hors négo) Ou encore (les deux sont équivalents) : (Nombre articles autorisés hors négo - nombre d'articles capturés hors négo) / nombre articles autorisés hors négo Les articles (dans le BI) peuvent avoir les statuts suivants : ITM_STATUS_CODE IDENTIFIER LABEL 10 RESERVED En attente de confirmation du vendeur 20 REQUESTED En attente de confirmation du vendeur 30 COMMITTED Le vendeur s'est engagé à livrer 40 CLOSED Reçu par l'acheteur 50 DELETED Supprimé 60 CANCELLED Annulé 70 ON_HOLD Réclamation en cours 100 REMINDED En attente de confirmation du vendeur Les articles autorisés regroupent les statuts 20,30,40,60,70,100 (on exclut 10 et 50) Les articles capturés regroupent les statuts 30,40,70 Ainsi, l'indicateur Cancellation rate répond à la formule ci-dessus. Par conséquent, il ne doit pas être utilisé dans un rapport n'ayant pas le filtre « Authorized items », afin d'éviter la division par 0. Il y avait tout de même une erreur dans la formule de calcul de l'ancien indicateur, qui a été corrigée. Je reste à votre dispo pour toute question. Merci, Cyril |
[INF-262] installation plugin Firefox Java Runtime Environment Création: 05/févr./09 11:17 Mise à jour: 30/mars/09 15:06 Résolue: 30/mars/09 15:06 |
|
| Etat: | Résolu |
| Projet: | Infrastructure |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Mathieu Richomme | Attribution: | Stéphane Eccli |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
salut Stéphane, ce plugin est nécessaire pour modifier mes rapports BI merci! Mathieu |
| Commentaires |
| Commentaire de Stéphane Eccli [ 30/mars/09 15:06 ] |
| pouet |
[INF-307] Excel 2007 pour JUG Création: 04/mai/09 17:11 Mise à jour: 12/mai/09 17:02 Résolue: 12/mai/09 17:02 |
|
| Etat: | Résolu |
| Projet: | Infrastructure |
| Composants: | Micro |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Agathe Remy | Attribution: | Stéphane Eccli |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Bonjour, Comme vu en point BI/Exploit et avec Philippe, il faudrait installer Excel 2007 sur le poste de Julien GIRARDET afin de lui permettre de traiter les demandes BI Finance. Merci. Agathe |
| Commentaires |
| Commentaire de Stéphane Eccli [ 12/mai/09 17:02 ] |
| ok pour excel |
[BIN-446] [Executive] : Nouveau rapport de suivi du nombre d'acheteurs uniques sur les 1, 3 et 6 derniers mois Création: 22/mai/08 14:19 Mise à jour: 08/juil./08 11:02 Résolue: 30/mai/08 17:41 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Executive |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Nouvelle fonctionnalité | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
active_buyer.sql
|
| Pays: |
FRA - France
|
| Description |
|
Il s'agit de transférer le rapport titan dans BI en ajoutant
le nombre d'acheteurs uniques sur les 12 et 24 derniers mois, ainsi
qu'une invite afin de sélectionner une date d'observation (i.e. avoir le
nombre d'acheteurs uniques des 6 derniers mois au 1er janvier 2008 ou
au 1er janvier 2007 par exemple). Faire les spécifications fonctionnelles (DMR), puis techniques (DSD) et développer le rapport dans BusinessObjects en Développement. Merci. Agathe |
| Commentaires |
| Commentaire de Agathe Remy [ 22/mai/08 14:21 ] |
| Voici le script titan de génération du rapport que l'on veut migrer dans BI. |
| Commentaire de Cyril Tanneau [ 30/mai/08 17:41 ] |
|
Le rapport est OK. Les résultats sont identiques à ceux de la requête sur l'integ. merci, Cyril |
| Commentaire de Cyril Tanneau [ 10/juin/08 17:04 ] |
|
Le nombre de mois a été calculé à partir du nombre de jours. De cette façon, nous avons : - 1 mois = 30 jours - 3 mois = 91 jours - 6 mois = 183 jours - 12 mois = 1 an = 365 jours Merci, Cyril. |
| Commentaire de Cyril Tanneau [ 11/juin/08 16:51 ] |
|
Bonjour, le rapport est terminé. Il se nomme "Active buyers follow up" et est disponible: - pour la France dans le dossier: France\Purchase; - pour l'Espagne dans le dossier: Spain\Purchase. Peux-tu valider le rapport? Merci, Cyril |
[BIN-497] [Finance] : Ecart sur compensation par chèque - aout Création: 26/sept./08 14:32 Mise à jour: 10/oct./08 12:56 Résolue: 10/oct./08 12:56 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Finance |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Samira Remila | Attribution: | Emeric Teil |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Agathe, Dalila, Comme vu ensemble,sur le mois d'aout écart constaté sur emission des chq : - rapport "compensation by method and closing date " : total payment = 402332,81 - fichier de suivi des chq émis du BO "fichier recollement" : total chq émis = 402323,04 soit un écart de 9.77 euros en trop sur le rapport BI je vous envoie un mail avec le tableau récapitulatif Pouvez-vous nous tenir informés rapidement merci à vous Samira |
| Commentaires |
| Commentaire de Samira Remila [ 30/sept./08 12:09 ] |
|
Comme vu ensemble,sur le mois de septembre aussi j'ai un écart sur emission des chq : - rapport "compensation by method and closing date " : total payment = 289138,16 - fichier de suivi des chq émis du BO "fichier recollement" : total chq émis = 288466,03 soit un écart de 672.13 euros en trop sur le rapport BI |
| Commentaire de Agathe Remy [ 03/oct./08 14:14 ] |
|
Emeric, Pourrais-tu, s'il te plait, commenter ce JIRA en décrivant le bug que vous avez identifié et me confirmer sa résolution à venir? Merci. Agathe |
| Commentaire de Dalila Belkebir [ 10/oct./08 12:56 ] |
|
Effectivement, Le problème est le suivant : certains vendeurs n'ont pas d'adresse de paiement (incohérence "historique" des données qu'on voit "remonter" suite au projet "inscription vendeur"). Les compensations pour ces vendeurs sont tout de même effectuées par le système et considérées comme "fermées". Cependant, ces vendeurs n'ayant pas de coordonnées de paiement, le script de l'exploit qui génère le fichier de compensations ne prend pas en compte les compensations ainsi générées (sans adresse). Ce qui nous concerne : -> pour Aout : 1 compensation -> pour Septembre : 6 compensations Ci-dessous, ce qu'Arnaud a trouvé pour le mois de Septembre : __________ "En effet, les compensations par chèque (1 en aout et 6 en septembre) qui n'ont pas d'adresse de paiement ont l'air de correspondre avec le décalage de paiement dont t'a parlé Philippe : SELECT SUM(payment_total) FROM compensation where cmp_status_code => 40 and cmp_method_code = 10 and usr_privilege_code = 10 and usa_last_name IS NULL; SUM(PAYMENT_TOTAL) = 681.9 ____________ Les 7 comptes concernés : LOGIN USR_PRIVILEGE_CODE CREATION_DATE -------------------------------------------------- ------------------ ------------------- ismav 40 09/10/2001 14:46:09 pailpail 40 06/03/2005 18:36:20 dda-l 40 23/12/2005 13:19:58 totove 40 15/11/2006 15:42:20 yann7950 40 11/12/2006 14:43:22 jupicat1 40 29/09/2007 21:44:01 MACULTURE 10 09/11/2007 20:26:37 On vous laisse trouver de votre côté un moyen pour régulariser ces situations. Du notre, on a déjà prévu de faire le nécessaire dans le cadre de la TX-C pour que cela ne se reproduise plus... EMERIC. |
[BIN-626] [PARAM] Les taux de reussite sont faux dans les rapports lorsque des lignes sont ignorées par les Imports Création: 20/août/09 16:33 Mise à jour: 28/sept./09 11:53 Résolue: 25/sept./09 15:56 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | BackOffice |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Frédéric Nahum | Attribution: | Geoffroy Vigneron |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
GBR - Royaume Uni, ESP - Espagne, FRA - France
|
| Description |
|
Je viens de me rendre compte que les rapports Import ne tienne pas compte des lignes ignorées Ex : Prenons un fichier de 10 000 lignes. Lignes totales : 10 000 lignes Lignes traitées : 1 000 lignes Lignes en erreurs : 100 lignes Lignes ignorées : 8 900 lignes Le taux de succès est donc de 99 % (lignes traitées + lignes ignorées) alors que dans le BI le taux de succès est de 10 % (car il ne tiens pas compte des lignes ignorées) Donc il faudrait considérer les lignes ignorées comme des lignes traitées mais surtout pas comme des lignes en erreur pour les taux ne soient pas faussé |
| Commentaires |
| Commentaire de Frédéric Nahum [ 20/août/09 16:36 ] |
|
Pour te donner un exemple de production le partenaire INTERNITY_FR est concerné par ce phénomène. Il est dans le BI au alentour de 10 % de réussite alors qu'il devrait être à 88 % Il y' a pas mal de fichier ou la majorité du fichier est ignorée (comme par exemple ignorer les stock à 0 et les mauvaises catégories) |
| Commentaire de Dalila Belkebir [ 18/sept./09 14:21 ] |
|
Bonjour Frédéric, Nous comptons modifier les dimensions dans les Univers. Voici la teneur de nos modifications : L'indicateur "Rejected line count" calculé comme ça : COUNT_ERRORS + COUNT_IGNORED va devenir COUNT_ERRORS L'indicateur "Success line count" calculé comme ça : COUNT_PROCESSED va devenir COUNT_PROCESSED + COUNT_IGNORED Es-tu OK ? Merci de ton retour pour modification immédiate ! Cdlt, dalila. |
| Commentaire de Frédéric Nahum [ 18/sept./09 17:57 ] |
|
Je dirais plus : L'indicateur "Rejected line count" calculé comme ça : COUNT_ERRORS va devenir COUNT_ERRORS Donc ca ne change pas L'indicateur "Success line count" calculé comme ça : COUNT_PROCESSED va devenir COUNT_PROCESSED + COUNT_IGNORED |
| Commentaire de Dalila Belkebir [ 25/sept./09 15:56 ] |
|
Bonjour Frédéric, La demande a été livrée, peux-tu stp nous la valider pour clôture du JIRA ? Merci. Cdlt, dalila. |
| Commentaire de Frédéric Nahum [ 25/sept./09 17:56 ] |
| oui c'est nikel |
OP de collecte 2010 - import de contacts
(CAT-3032)
|
|
| Etat: | Résolu |
| Projet: | Paramétrage - Non Import |
| Composants: | Import de contacts Marketing |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Sub-bug | Priorité: | Bloquant |
| Rapporteur: | Carole Boucheny | Attribution: | Carole Boucheny |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||||||||||
| Pays: |
FRA - France
|
||||||||||||||||
| Description |
|
Dans nos scripts les colonnes correspondants aux abonnements
à VMC et AVAL sont nulles. Or le batch d'import de contact semble mal
gérer ce cas.
Il faut donc : -> Extraire tous les contacts à désabonner de ces newletters et l'envoyer au BI -> Demander au DBA de désabonner ces contacts de ces newletters -> Modifier tous les scripts d'import de contact pour que cette colonne soit toujours à 0 et non nulle -> Metter à jour les tables temporaires. |
| Commentaires |
| Commentaire de Carole Boucheny [ 02/nov./10 15:43 ] |
| Les tables temporaires ont toujours 0 dans les colonnes correspondant à l'abonnement aux newletters VMC et AVAL. |
| Commentaire de Carole Boucheny [ 02/nov./10 15:56 ] |
|
Les scripts ont été modifié pour avoir 0 par défaut pour les colonnes concernées.
Les tables temporaires ont été mise à jour. En ce qui concerne le désabonnement en prod, ceci ne pourra être fait qu'à partir de jeudi par Patrick. |
| Commentaire de Carole Boucheny [ 02/nov./10 16:09 ] |
|
La correction a faire son dû au problème de ce jira : APP-31579 (mauvaise gestion du null par le batch d'import de contact).
|
| Commentaire de Carole Boucheny [ 02/nov./10 17:25 ] |
|
Le BI n'a finalement pas besoin de l'extract :
"En fait, nous ne faisons que transmettre les données de la base OLTP aux partenaires. Corriger nous-même les données demanderait des développements coûteux et ne correspondrait plus à notre philosophie qui est de restituer les informations de la base de données du site. Donc on attend la correction en Production. Agathe" Il faut donc attendre le retour de Patrick pour pouvoir résoudre ce problème. (Il revient jeudi) |
| Commentaire de Carole Boucheny [ 05/nov./10 14:52 ] |
| Les contacts qui avaient été abonné à AVAL et VMC ont été désabonné dans notre base. |
[BIN-528] extraction du stock pro alphalibris Création: 15/déc./08 10:55 Mise à jour: 17/déc./08 15:38 Résolue: 15/déc./08 18:09 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Sales |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Bloquant |
| Rapporteur: | Anne Korchia | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
bonjour je n'arrive pas à faire une extraction de stock pour le pro alphalibris sur bi ça bloque, le parma ne peut le faire non plus pourriez vous m'aider? Merci |
| Commentaires |
| Commentaire de Cyril Tanneau [ 15/déc./08 18:09 ] |
|
Anne, tu trouveras le fichier d'export de stock d'Alphalibris au format CSV dans le dossier suivant, sur W. W:\agathe\Export_de_stock_alphalibris_081215 La requête était en effet très couteuse, le stock de ce vendeur étant relativement important. Je te laisse revenir vers nous si tu as des questions. Merci, Cyril. |
| Commentaire de Anne Korchia [ 15/déc./08 18:12 ] |
| merci beaucoup ! |
[cob] META-TACHE Fermeture Epik
(APP-25109)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 52.0.0 (CTN-M) |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | Fabrice Feugas | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM: | *** RESERVE *** |
| Description |
|
Le cob Epik sera inactif à partir du 01/07/2009. Merci d'arrêter les rapports BI en même temps. |
| Commentaires |
| Commentaire de Agathe Remy [ 30/avr./09 11:40 ] |
|
Arrêt du listing mensuel des nouveaux membres le 03/07 Arrêt du reporting hebdo le 06/07 Agathe |
| Commentaire de Cyril Tanneau [ 29/juin/09 12:42 ] |
|
Les rapports de cobranding EPIK ont bien été arrêtés à la date spécifiée dans le JIRA, Merci, Cyril Tanneau |
| Commentaire de Cyril Tanneau [ 29/juin/09 12:48 ] |
|
Erreur de ma part, les rapports de cobrandings EPIK seront arrêtés Respectivement Vendredi prochain pour le listing mensuel et Lundi prochain pour le reporting hebdomadaire. Merci, Cyril Tanneau |
| Commentaire de Fabrice Feugas [ 29/juin/09 15:31 ] |
| Ouf, ok merci. |
| Commentaire de Christophe Garcia [ 29/juin/09 15:42 ] |
| MDPLVC |
[cob] META-TACHE Fermeture Dauphiné Libéré et CamifOccasion
(APP-25678)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 53.0.4 |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | Fabrice Feugas | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM: | *** A PLANIFIER *** |
| Description |
|
Le cob Dauphiné Libéré et CamifOccasion seront inactifs à partir du 15/09/2009. Merci d'arrêter les rapports BI en même temps. |
[cob] META-TACHE Fermeture LeProgrès
(APP-28357)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 67.0.0 (CTN-Q) |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | Fabrice Feugas | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM: | *** RESERVE *** |
| Description |
|
Le cob LeProgrès sera inactif à partir du 15/03/2010. Merci d'arrêter les rapports BI en même temps. |
| Commentaires |
| Commentaire de Fabrice Feugas [ 18/févr./10 18:08 ] |
| Reporting hebdos et nouveaux inscrits. |
| Commentaire de Fabrice Feugas [ 29/mars/10 12:02 ] |
| Déjà fait depuis un moment :) |
[CAT-2995] [Flux comparateur] Lister les flux existants Création: 11/août/10 17:52 Mise à jour: 23/août/10 11:06 Résolue: 23/août/10 11:06 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Non Import |
| Composants: | Flux Marketing |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Carole Boucheny | Attribution: | Carole Boucheny |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
flux_http.txt
|
| Pays: |
ALL - Tous
|
| Description |
|
Voici la demande de Thierry : _ Lister les urls des flux _ Lister les flux accessibles par d'autres biais |
| Commentaires |
| Commentaire de Carole Boucheny [ 23/août/10 10:46 ] |
| Ci-joint la liste des flux disponibles en http |
| Commentaire de Carole Boucheny [ 23/août/10 10:52 ] |
| Il ne s'agit que des flux pour la France |
| Commentaire de Thierry Leforestier [ 23/août/10 11:06 ] |
| Merci Carole, c'est suffisant pour le moment :) |
[APP-501] Generation et envoie automatique 2 fois par semaine a mettre en place... Création: 14/juin/01 10:21 Mise à jour: 25/juin/07 18:21 Résolue: 25/juin/07 18:21 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | old |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Justin Ziegler | Attribution: | Jean-François Mach |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
... meme date que les autres rapport bi hebdo. Destinataires : nath, olivier.mathiot, jz |
[APP-30959] [Coupon rendu monnaie] Modification du secret name associé au coupon avoir Création: 13/sept./10 12:19 Mise à jour: 17/sept./10 11:11 Résolue: 13/sept./10 16:59 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 77.0.0 (TX-P) |
| Version(s) corrigée(s): | 77.0.0 (TX-P) |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Thomas Landru | Attribution: | Yann Danot |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Site: | Dev |
| Projets PM: | Paiement - Coupon et rendu monnaie |
| Navigateur: | Tous |
| Description |
|
Modifier le secret name du coupon associé à l'utilisateur
pour faciliter l'exploitation des résultats en BI : SECRETNAME_AVOIR_ID
|
[IMP-8088] C'est la fin des SOLDES > mettre à jour le titre des annonces asap car potentiel problème avec la DGCCRF > MILO-78 Création: 17/févr./11 10:44 Mise à jour: 17/févr./11 16:17 |
|
| Etat: | Ouvert |
| Projet: | Paramétrage - Import |
| Composants: | Demande commerciale |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Isabelle Weisbecker | Attribution: | Dispatcher (Param-Import) |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Advert listing by login_milo-78_17.02.2011.csv
|
| Pays: |
FRA - France
|
| Login: | MILO-78 |
| Modèle: | extraction BI |
| Séparateur: | N/A |
| Type de traitement: |
Mise à jour/création annonces avec mise à jour/création produits
|
| Description |
|
c'ets la fin des soldes, le pro n'a pas accès aux titres
pour les modifier. pourriez-vous mettre à jour les annonces avec
l'extraction BI ci-joint. merci.
|
[BIN-597] [tracking Keyade] analyse des purchase id Création: 23/juin/09 12:52 Mise à jour: 08/juil./09 19:10 Résolue: 08/juil./09 19:10 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Mathieu Richomme | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
LS - Paniers Keyade.xls
|
| Pays: |
FRA - France
|
| Description |
|
Bonjour, voici une liste de purchase id marqués LS en base chez nous (vérifié avec Swan) ils sont présents dans la base Keyade mais pas dans mon rapport "LS - Paniers Keyade" (dossier Mathieu) en PJ le rapport BI en question, sorti pour le 17/06, pour les 6 tracking group commençant par "LS-" j'ai vérifié le rapport public "Purchase by purchase tracking 30 days", il me sort le même nombre de paniers que mon rapport perso (c'est le même rapport avec la colonne purchase id en plus) d'avance merci pour votre aide sur le sujet, à votre dispo pour en rediscuter si ce n'est pas clair Mathieu 72458402 72474445 72459005 72455405 72455732 72455817 72456211 72456234 72456252 72456334 72456343 72456448 72457172 72464751 72487778 72466098 72474631 72469344 72470366 72471930 72485736 72472573 72454754 72454725 |
| Commentaires |
| Commentaire de Mathieu Richomme [ 08/juil./09 18:53 ] |
|
vu avec Agathe, concernant les 24 paniers du 17/06 remontant chez Keyade et pas dans BI: - pour 11 paniers, le jour de creation est différent du jour d'autorisation => normal qu'ils ne remontent pas dans le rapport (ex: créé le 16/06 à 23h55 et autorisé après minuit) - pour 1 panier, la différence entre la date de creation et la date de depôt du cookie est > à 30 jours => bizarre qu'il remonte via le tag mais négligeable - pour 12 paniers c'est lié à un problème déjà identifié et en cours de résolution => négligeable de toute manière vu les volumes on est donc bon sur le tracking ;)) merci! Mathieu |
| Commentaire de Mathieu Richomme [ 08/juil./09 18:56 ] |
| "remontant chez Keyade et pas dans le rapport Purchase by Purchase Tracking" pour être précis ! |
| Commentaire de Agathe Remy [ 08/juil./09 19:10 ] |
| Merci Mathieu! |
[APP-18288] DB Integ : Tables obsoletes Création: 18/oct./07 16:51 Mise à jour: 11/mars/10 10:20 Résolue: 10/mars/10 18:13 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 17.0.0 |
| Version(s) corrigée(s): | 63.0.3 |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Quentin de Chivré | Attribution: | Ayoub Benseghir |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
obs_tab.xls
obs_tab.xls
|
| Pays: |
FRA - France
|
| Site: | Integ |
| Projets PM: | *** A PLANIFIER *** |
| Description |
|
Les tables suivantes ne me paraissent pas utilisées (elles sont en Integ et donc probablement aussi en Prod) => on doit pouvoir faire du ménage (après vérification...) administration : BACK_CATEGORY_TRANSLATION FEED_PRODUCT_URL summary : MV_CAPABILITIES_TABLE user : BACKUP_COUNTRY TEMP_LOGIN purchase : CK_LOG product : BACK_PRD_FRONT_CATEGORY BACK_PRD_FRONT_CLASSIFICATION BACK_PRD_BACK_CATEGORY APP8180 OPTIMIZATION_DATE CK_LOG INDEX_REPORT XRES TEST_BI TMP_CAT VAT_TO_DELETE DYNAMO_NEW TEMP_ID TEMP_PRODUCT_URL SAV_DISPLAY_UNIT SAV_STACK SHOES_TO_MIGRATE |
| Commentaires |
| Commentaire de Quentin de Chivré [ 15/avr./08 14:08 ] |
|
Nouvelle liste : *** Product : Tables à supprimer ? APP8180 BACK_PRD_BACK_CATEGORY BACK_PRD_FRONT_CATEGORY BACK_PRD_FRONT_CLASSIFICATION SAV_DISPLAY_UNIT SAV_STACK SHOES_TO_MIGRATE TEMP_ID TEMP_PRODUCT_URL TEST_BI TMP_CAT VAT_TO_DELETE Tables DBA ? DYNAMO_NEW CK_LOG XRES INDEX_REPORT OPTIMIZATION_DATE *** Administration : BACK_CATEGORY_TRANSLATION HELP => Dev HLP_* => Dev *** Purchase : CK_LOG *** Summary : MV_CAPABILITIES_TABLE SEARCH_HISTORY => Dev SHI_PAGE_CODE => Dev *** User : BACKUP_COUNTRY TEMP_LOGIN USR_EVENT_NEW |
| Commentaire de Quentin de Chivré [ 08/juil./08 11:29 ] |
|
Quelles tables ont étés suppriméesfinalement ? Toutes celles ci-dessus ? Certaines devaient plutot l'etre par le dev, des fonctionnalités risqueraient de ne plus marcher, voire meme le build pourrait etre cassé si on vire des tables de code référencéesr l'appli (je pense aux tables marquées => Dev dans mon commentaire précédent) |
| Commentaire de Ayoub Benseghir [ 08/juil./08 11:39 ] |
| Pour l'instant il n'y pas de tables supprimées. Certaines sont toujours utilisées et ne seront pas supprimées (ex: DYNAMO_NEW), d'autres ont été renommées en DEV et en INTEG (script en V25) en attendant un éventuel retour des devs ou autre et enfin une dizaine de tables sont monitorées en prod pour confirmer/infirmer leur non utilisation. |
| Commentaire de Quentin de Chivré [ 08/juil./08 12:40 ] |
|
C'est possible d'avoir en PJ du Jira un fichier XL qui dit
précisemment ce qu'on a fait sur chaque table ? Renommage / monitoring /
conservation ? Un renommage sur les tables qui m'inquietent (vois commentaire précedent) aura le même effet "plantage du build" |
| Commentaire de Ayoub Benseghir [ 09/juil./08 10:29 ] |
| Actions sur les tables obsolètes |
| Commentaire de Quentin de Chivré [ 09/juil./08 11:06 ] |
|
Merci c'est clair. Au final rien n'a été fait sur les tables suivantes : HELP => Dev HLP_* => Dev SEARCH_HISTORY => Dev SHI_PAGE_CODE => Dev Ca me parait bien car le mieux est que le Dev supprime ces tables en même temps que le code appli associé. Ceci dit je me suis trompé sur les histoires de build, on fait tout sur la base de Dev et plus sur la base d'integ comme par le passé, donc les pbs seraient ** eventuellement ** apparus au démarrage de JBoss, pas au build. |
| Commentaire de Quentin de Chivré [ 09/juil./08 11:07 ] |
|
Ceci dit, je trouve mieux de réouvrir le Jira jusqu'a ce
qu'on ai les conclusions et qu'on décide de rééllement supprimer les
tables ou pas. Non ? |
| Commentaire de Ayoub Benseghir [ 24/juil./08 10:40 ] |
| Les tables qui étaient en auditées sont maintenant renomées en dev en en integ. |
| Commentaire de Ayoub Benseghir [ 10/oct./08 11:38 ] |
| Misa a jour |
| Commentaire de Ayoub Benseghir [ 10/oct./08 11:41 ] |
| Les tables qui ont été renommées sont maintenant supprimées en dev et en integ. cf obs_tab.xls pour les détails |
| Commentaire de Ayoub Benseghir [ 10/mars/10 11:39 ] |
| c'est fait |
| Commentaire de Christophe Garcia [ 10/mars/10 18:11 ] |
| MDPLVC |
[APP-27767] Problème sur la pose des Tags d'un partenaire en affiliation: Effiliation Création: 23/déc./09 17:42 Mise à jour: 28/janv./10 11:43 Résolue: 19/janv./10 09:15 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Affiliation |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 61.0.0 (CTN-O) |
| Type: | Bogue | Priorité: | Bloquant |
| Rapporteur: | Jonathan Gorges | Attribution: | Swan Desportes |
| Résolution: | Aucune correction envisagée | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Exemple de panier remontant sur
la plateforme sans last tracking 30 jours sur la journée du 10 decembre
2009.xls
|
||||||||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Projets PM: | *** CHASSE *** | ||||||||
| Description |
|
Bonjour, Nous venons de déceler un problème majeur en affiliation. Constat: Notre plateforme d'affiliation "Effiliation" remonte beaucoup plus de paniers autorisés que nos reporting BI. Pourquoi? Après avoir testé plusieurs paniers dans le back office, il apparaît que la plateforme Effiliation remonte des paniers qui ont plus de 30 jours. Il s'agit par exemple de 550 paniers en trop pour la date du 10/12/2009 Exemple: Panier n°: 79229229 Création du panier: 10/12/2009 Tracking de session : Affiliationx-Netavenir-bannieres (905640) 06/10/2009-03:33 - Indirect Les affiliés voient donc beaucoup de ventes remonter sur leur extranet que nous ne devons pas payer. Pourriez-vous nous aider à vérifier si tout fonctionne bien côté PriceMinister svp? Nous faisons nos recherches côté plateforme d'Effiliation. Merci d'avance pour votre aide. JG |
| Commentaires |
| Commentaire de Jonathan Gorges [ 23/déc./09 17:43 ] |
| En pièce jointe un extract des paniers qui posent problème. |
| Commentaire de Jonathan Gorges [ 23/déc./09 17:49 ] |
|
Bonjour, Nous venons de voir avec la plateforme et ils nous assurent qu'aucune modification n'a été faite (concernant les cookies par exemple), durant cette période. Le problème semble ce trouver chez nous. Merci d'avance pour votre aide à ce sujet. Jonathan. |
| Commentaire de Marion Anfreville [ 05/janv./10 13:05 ] |
| Est-ce que le problème est toujours d'actualité ? |
| Commentaire de Jonathan Gorges [ 05/janv./10 14:01 ] |
|
Hello, Effectivement, ce problème est toujours d'actualité. Pour ma part, je travaille étroitement avec la plateforme d'affiliation pour voir si l'on peut déceler le moindre problème. Avez-vous constaté qqchose de votre côté? Merci |
| Commentaire de Olga Costa [ 05/janv./10 14:21 ] |
|
Jonathan, tu parles des tag buy, first buy ou première mise en vente? De notre coté nous pouvons faire un test pour vérifier si il s'agit d'un tracking moins de 30 jours. Nous faisons déjà ce test pour les tags de première mise en vente. Mais il n'a jamais été fait pour les buy et first buy quel que soit la plateforme (zanoxx, affilinet etc..). Si le pb vient du fait que nous ne faisons pas ce test alors ce pb doit exister pour les autres plateformes aussi. |
| Commentaire de Jonathan Gorges [ 05/janv./10 14:35 ] |
|
Hello, Merci pour ce retour. Le problème constaté concerne aujourd'hui le tracking buy. Effectivement, pourriez-vous faire un test comme précisé ci-dessus? Merci d'avance |
| Commentaire de Swan Desportes [ 05/janv./10 14:41 ] |
|
[CAJ2010Q1CTN] Hello Jonathan, Nous ne pouvons malheureusement rien y faire. A moins d'organiser un développement en urgence... Le fonctionnement est tout à fait normal. La limitation 30 jours est une notion BI. Elle n'a pas d'existence côté site PM. Il est donc tout à fait possible de remonter des tags Effiliation à plus de 30 jours. A mon avis, les siteunders devaient en masquer une bonne partie. C'est pour cela que l'on en voit beaucoup maintenant. Est ce qu'il y a moyen de demander à Effiliation de ne pas tenir compte de ces paniers + de 30 jours ? Merci Swan |
| Commentaire de Jonathan Gorges [ 06/janv./10 08:56 ] |
|
Hello Swan, Merci pour ce commentaire et tes recherches. Effectivement, nous allons demander à Effiliation ne pas tenir compte de ces paniers. Merci. JG |
| Commentaire de Christophe Garcia [ 06/janv./10 15:11 ] |
| MDPLVC |
[BIN-210] Correction rapport BO "payment by purchase" Création: 26/oct./06 17:18 Mise à jour: 14/sept./07 17:31 Résolue: 15/déc./06 18:44 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Executive |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Critique |
| Rapporteur: | Philippe Favrot | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Encaissement journée du 30 sept 06.xls
Encaissement journée du 30 sept 06.xls
|
| Pays: |
ALL - Tous
|
| Description |
|
mon mail du 25/10 reproduit ci-après : Je me rends compte que je n'avais pas joint le fichier... depuis, j'ai travaillé sur une journée plus récente (30 septembre) incluant des transactions payées via 1¿.com. Sauf erreur de ma part, le rapport « payment by purchase » inclus les transactions financées par 1¿.com ; peux tu vérifier car tu m'avais indiqué le contraire. Il faudrait que ces transactions soient clairement identifiées dans ce rapport ; par exemple par une mention spécifique dans la colonne « card type » qui est actuellement vierge de toute mention lorsqu'il s'agit d'un paiement via 1¿.com. Par ailleurs, tu constateras donc des écarts au niveau du « Authorized GMS » ; peut être un lien avec mon mail du 20 septembre. Merci de ton retour Philippe -------------------------------------------------------------------------------- De : Philippe FAVROT [mailto:philippe.favrot@priceminister.com] Envoyé : lundi 23 octobre 2006 11:28 À : 'Agathe Remy'; 'pierre.krings@priceminister.com' Cc : 'justin.ziegler@priceminister.com' Objet : RE: BI Finance Agathe, « Payment by purchase » : suite à notre réunion de mercredi, j'ai donc procédé à la réconciliation de la journée du 30 juin 2006 entre BO et Titan ; voir le fichier en pièce attachée. On a donc des écarts sur la partie « Authorized GMS ». Par ailleurs, pour boucler cette partie « suivi des encaissements », il faut un rapport similaire pour le type de paiement 1euros.com. Merci Philippe |
| Commentaires |
| Commentaire de Agathe Remy [ 31/oct./06 10:55 ] |
|
Bonjour Philippe, J'ai ajouté la colonne payment type dans le rapport payment by purchase afin que tu puissent identifier les paiements 1euros. Cela te convient-il? Merci:-) Agathe |
| Commentaire de Philippe Favrot [ 31/oct./06 19:46 ] |
|
Bonsoir Agathe, merci pour cette modif. mais je suis un peu troublé car le rapport ne donne plus le même résultat qu'avant ta modification (sur la base de la journée du 30 septembre) ; voir le fichier attaché. Par ailleurs, peux tu mettre en place une invite sur le "card type" et une autre sur le "payment type". Merci Philippe |
| Commentaire de Agathe Remy [ 02/nov./06 14:23 ] |
|
Bonjour Philippe, La différence de résultat était du au fait qu'en rajoutant le payment type, j'ai exclu toutes les transactions sans type de paiement (payées uniquement par PMV). J'ai corrigé cette erreur et maintenant, tu dois trouver les mêmes résultats que précédemment (j'ai vérfié). D'autre part, j'ai ajouté les invites sur card type et payment type. Si tu veux ne pas sélectionner de valeur particulière, il faut saisir % à la main dans l'invite. Cordialement, Agathe |
| Commentaire de Philippe Favrot [ 03/nov./06 11:44 ] |
|
Bonjour Agathe, merci ; effectivement la requête donne à présent le même résultat qu'initialement. Reste donc àtraiter l'écart sur l'indicateur "Authorized GMS". Philippe |
| Commentaire de Agathe Remy [ 24/nov./06 14:33 ] |
|
Bonjour Agathe, Serait il possible d'intégrer dans le rapport payment by purchase les informations suivantes : N° transaction Sips N° autorisation Sips Merci Philippe |
| Commentaire de Philippe Favrot [ 04/déc./06 10:31 ] |
|
Agathe, suite à notre réunion du 21 nov. Concernant les écarts mis en évidence au niveau de l'authorized GMS, merci d'ajuster sur le rapport "purchase summary" ==> les transactions isolées dans l'onglet 5 ne doivent donc pas être reprises dans le rapport "payment by purchase". Pour les autres écarts (cf onglet 4), c'est à toi d'investiguer. Merci Philippe |
| Commentaire de Agathe Remy [ 14/déc./06 18:55 ] |
|
Philippe, Si, comme tu le dis, les transactions isolées dans l'onglet 5 ne doivent pas apparaître dans le rapport "payment by purchase", cela signifie que nous excluons de ce rapports : - les paniers passés en CONFIRMATION_DENIED - les paniers de type négociation ayant été annulés Peux-tu me le confimer? Doit-on aussi exclure les paniers auto (pack vendeur, garanties) qui ne sont pas dans le rapport "Purchase summary by month"? Merci:-) Agathe |
| Commentaire de Agathe Remy [ 14/déc./06 19:14 ] |
|
Voici le résultat de mon investigation sur les écarts de l'onglet 4 : Dans BI : Authorized GMS = Authorized payment amount + Authorized coupon amount Dans Titan : Authorized GMS = Authorized payment amount + Captured coupon amount Cette différence de formule explique ces écarts. Il me semble donc que le rapport BI est plus cohérent que celui de Titan, mais, sachant que dans le rapport "Purchase summary by month", le champ Authorized GMS = Authorized payment amount + Captured coupon amount (comme dans Titan), à toi de juger ! Merci:-) Agathe |
| Commentaire de Agathe Remy [ 14/déc./06 19:25 ] |
|
Les colonnes N° transaction Sips et N° autorisation Sips ont été ajoutées au rapport "Payment by purchase". J'ai supposé que le N° transaction Sips correspondait au champ "Authorization number request" et le N° autorisation Sips au champ "Authorization number response". Peux-tu me dire si cela te parait correct? Merci:-) Agathe |
| Commentaire de Philippe Favrot [ 15/déc./06 13:47 ] |
|
Bonjour Agathe, mes commentaires à tes questions de ces derniers jours sur ce rapport : 1 - Si, comme tu le dis, les transactions isolées dans l'onglet 5 ne doivent pas apparaître dans le rapport "payment by purchase", cela signifie que nous excluons de ce rapports : - les paniers passés en CONFIRMATION_DENIED - les paniers de type négociation ayant été annulés Peux-tu me le confimer? oui je confirme ; l'objectif est d'aligner la façon de déterminer le VA autorisé entre les différents rapports. D'ailleurs, sauf erreur de ma part tu as déjà fait cette modification ? 2 - Doit-on aussi exclure les paniers auto (pack vendeur, garanties) qui ne sont pas dans le rapport "Purchase summary by month"? effectivement les paniers auto ne sont pas repris dans le rapport "purchase summary" ; néanmoins il est impératif de les maintenir dans le rapport "payment by purchase" car ce rapport est avant tout destiné à suivre canal / canal l'encaissement des achats (or en matière d'encaissement, les paniers auto suivent le même traitement que les paniers classiques achat-vente). 3 - Voici le résultat de mon investigation sur les écarts de l'onglet 4 : Dans BI : Authorized GMS = Authorized payment amount + Authorized coupon amount Dans Titan : Authorized GMS = Authorized payment amount + Captured coupon amount Cette différence de formule explique ces écarts. Il me semble donc que le rapport BI est plus cohérent que celui de Titan, mais, sachant que dans le rapport "Purchase summary by month", le champ Authorized GMS = Authorized payment amount + Captured coupon amount (comme dans Titan), à toi de juger ! On est donc d'accord que le VA autorisé tel que déterminé dans le rapport BI "payment by purchase" est celui qui est exact. Néanmoins je n'ai pas envie qu'on retouche pour l'instant au rapport "purchase summary by month" donc je suggère de modifier "payment by purchase" (le VA autorisé est un indicateur de gestion et pas une donnée qui est comptabilisé ; donc cette erreur est supportable d'autant plus qu'ele porte sur des montants faibles). 4 - Les colonnes N° transaction Sips et N° autorisation Sips ont été ajoutées au rapport "Payment by purchase". J'ai supposé que le N° transaction Sips correspondait au champ "Authorization number request" et le N° autorisation Sips au champ "Authorization number response". Peux-tu me dire si cela te parait correct? J'ai pris le purchase ID : 38996672 ds le Back Office : on a : N° transaction Sips = 186 136 N° autor Sips = 929 829 ds ton rapport : on a : Sips transaction number = 186 136 Sips autorisation number = 926829 Ca me semble être ok Reste doncd le point 4 à modifier et on devrait être bon pour ce rapport Merci Philippe |
| Commentaire de Agathe Remy [ 15/déc./06 18:44 ] |
|
Le VA autorisé a été modifié dans la rapport Payment by purchases. Cordialement, Agathe |
| Commentaire de Philippe Favrot [ 19/déc./06 09:56 ] |
|
Bonjour, sur la base de la journée du 30 septembre ça fonctionne maintenant. Donc sous réserve d'anomalies que mettrait en évidence une "utilisation plus intensive" du rapport c'est ok pour moi. Tu peux fermer le Jira. Philippe |
[EXP-666] Déploiement outil de supervision MINITOR sur LATONE Création: 22/déc./05 16:49 Mise à jour: 25/juin/07 18:55 Résolue: 23/déc./05 10:52 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Sébastien Tournay | Attribution: | Xiaoming Du |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Xiaoming, On vient de déployer en PROD le serveur LATONE. C'est un serveur que nous allons utiliser pour la bdd BI. Pourrais-tu lui installer MINITOR avec un profil BDD. On pourra le faire évoluer ensuite pour des besoins spécifiques BI. Il faut aussi penser à le mettre dans notre boucle de ping pour détecter les arrêt et reboot. |
| Commentaires |
| Commentaire de Xiaoming Du [ 23/déc./05 10:52 ] |
|
http://intra.priceminister.com/qvpm.html Latone arrive. |
[DEC-351] Nombre membres, acheteurs, abonnés news depuis 2004 mois par mois Création: 17/mai/06 10:13 Mise à jour: 14/sept./07 14:40 Echéance: 24/mai/06 00:00 Résolue: 27/juin/06 16:42 |
|
| Etat: | Fermé |
| Projet: | Reporting |
| Composants: | Marketing |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Odile Szabo | Attribution: | Agathe Remy |
| Résolution: | Invalid | ||
| Estimation restante: | 4 heures | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | 4 heures | ||
| Description |
|
samir m'a dit qu'il était possible de sortir sur BI le
nombre de membre , d'acheteurs, d'abonnés à une news (et pas offres
partenaires) mois par mois de puis 2004. merci Odile |
| Commentaires |
| Commentaire de Samir Beghdadi [ 22/mai/06 12:35 ] |
|
Slt, Voila je te réassigne le jira de la demande d'Odile pour le nombre de membre et d'acheteurs mois par mois de puis 2004, le rapport se trouve dans le dossier Purchase/V1.1/User-Bayer odile, concernant le nombre d'abonnés à une news (et pas offres partenaires) mois par mois de puis 2004, le rapport a été déjà généré par Cyrille. Merci. |
[EXP-2979] "preview.priceminister.es" accès de chez moi Création: 13/nov./06 09:36 Mise à jour: 25/juin/07 18:59 Résolue: 15/nov./06 11:08 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Yassine Mouhammadou | Attribution: | Patrice Boulanger |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ESP - Espagne
|
| Description |
|
Par curiosité, j'ai essayé de me connecter sur http://preview.priceminister.es/ de chez moi ce WE, et j'ai eu l'accès (par le biais de la saisie de log et mdp)
|
| Commentaires |
| Commentaire de Antoine Koener [ 15/nov./06 11:08 ] |
|
Merci, d'avoir testé. Cela veut dire que ca marche même depuis chez toi. Pour bloquer j'attends le calendrier. |
[DEC-639] [Référencement] : Nouvel export Widgets Création: 19/nov./08 16:54 Mise à jour: 07/avr./09 14:49 Résolue: 20/nov./08 15:04 |
|
| Etat: | Fermé |
| Projet: | Reporting |
| Composants: | Marketing |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Thierry Leforestier | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
URL_widgets_FR_ES_20081120.xls
|
| Pays: |
FRA - France
|
| Description |
|
Nous avons besoin d'un nouvel export des données du BI pour
les widgets afin d'étudier l'impact éventuel des liens synergie en
France. Merci d'avance ! |
| Commentaires |
| Commentaire de Agathe Remy [ 20/nov./08 15:04 ] |
|
Thierry, Tu trouveras ci-joint le nouvel export des widgets boutique et parrainage FR et ES. Le fichier est également présent dans le répertoire : V:\Reporting\Maintenance\Developpement\Url widgets Agathe |
[APP-22653] [UK] Ajouter promo frais de port gratuit sur toutes les pages de nav Création: 21/oct./08 14:54 Mise à jour: 22/déc./08 11:39 Résolue: 16/déc./08 10:53 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Promo |
| Affecte la/les version(s): | 31.0.3, 35.0.0 (CTN-H) |
| Version(s) corrigée(s): | 37.0.0 (TX-D) |
| Type: | Nouvelle fonctionnalité | Priorité: | Majeur |
| Rapporteur: | Charles Decaux | Attribution: | Rémi Virlouvet |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
free-delivery-459x43-01.swf
|
||||
| Liens des demandes: |
|
||||
| Pays: |
GBR - Royaume Uni
|
||||
| WishList: | Marketing | ||||
| Classif2: | contenu | ||||
| Classif FONC: | comarket | ||||
| Projets PM archivés: | UK - Adaptations fonctionnelles | ||||
| Description |
|
Lors de la sortie du site UK, on voudrait mettre en avant
les frais de port à 0 par le biais d'une promo ressemblante à ce qu'on a
fait pour MVNO sur la France.
|
| Commentaires |
| Commentaire de Charles Decaux [ 27/oct./08 14:08 ] |
|
Le mieux serait de se baser sur le travail effectué par
Corinne sur la home page sur les frais de port gratuit et de se servir
de ce travail pour le décliner en tant que promo sur les autres pages du
site. Voir : T:\00_Maquettage\00_Projets\PM_UK\HP\home_uk_changement_wording.png |
| Commentaire de Jérôme Viviès [ 19/nov./08 09:03 ] |
|
??? Je pense qu'il va falloir nous fournir une créa précise. Merci de te renseigner auprès de Benjamin pour connaitre les modalités de mise en place des cette promo et de repréciser ta demande, stp. |
| Commentaire de Charles Decaux [ 19/nov./08 09:41 ] |
|
Hello, vu avec Gafour : il se cale sur votre planning pour
vous livrer la créa. Je lui ai indiqué que vous travaillerez dessus en
S49 J'affecte donc le JIRA à Gafour. Merci |
| Commentaire de Gafour Abdoul [ 19/nov./08 18:42 ] |
| Charles, vu que ça sera fait par le webdesign market, je le réattribue au Param. |
| Commentaire de Charles Decaux [ 19/nov./08 18:57 ] |
|
Ok très bien, la créa sera livrée le 26 novembre. Merci |
| Commentaire de Ariane Baldinger [ 15/déc./08 15:43 ] |
|
Charles, On a besoin de précision : - Le paramétrage doit se faire sur le Location_alias = FILTER_NAVIGATION ? - Position Body inside? - Il faut mettre la bannière sur toutes les familles produits ? |
| Commentaire de Charles Decaux [ 15/déc./08 17:08 ] |
|
La réponse est oui à toutes les questions ! Merci Ariane :-) |
| Commentaire de Rémi Virlouvet [ 15/déc./08 18:01 ] |
| Cette bannière a été refaite en v2 suite à des soucis en HomePage non? je prends la v2 ou c'est autre chose? |
| Commentaire de Charles Decaux [ 15/déc./08 18:05 ] |
|
oui il faut prendre la deuxième version qui corrige un pb d'alignement du texte merci |
| Commentaire de Rémi Virlouvet [ 15/déc./08 18:26 ] |
| Olga, testage now :) |
| Commentaire de Rémi Virlouvet [ 15/déc./08 18:27 ] |
| Please ^^ |
| Commentaire de Rémi Virlouvet [ 15/déc./08 18:31 ] |
|
Charles, tu peux tester en dev. |
| Commentaire de Olga Costa [ 15/déc./08 18:33 ] |
| ok pour moi |
| Commentaire de Charles Decaux [ 15/déc./08 19:04 ] |
|
Ok c'est bon, merci |
| Commentaire de Rémi Virlouvet [ 16/déc./08 10:10 ] |
| /promotions/Promotions/GB/Promos/Free UK Delivery |
[APP-21182] [MODULE VENDEUR] Etape 1 : Pouvoir sélectionner un widget en cliquant sur l'image Création: 10/juil./08 14:07 Mise à jour: 08/sept./08 10:30 Résolue: 16/juil./08 15:05 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 25.0.0 (CTN-D) |
| Version(s) corrigée(s): | 28.0.0 (CTN-F) |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Cédric Goldovsky | Attribution: | Clement Balay |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
screenshot-1.jpg
|
| Pays: |
ALL - Tous
|
| Site: | Integ |
| Projets PM archivés: | MKT communautaire (Label Vendeur) |
| Description |
|
Etape 1 : Il pourrait être user friendly que le choix d'un
widget (boutique ou catégorie) ne se fasse pas exclusivement par le
biais des radio boutons et que les images soient cliquables.
|
| Commentaires |
| Commentaire de Clement Balay [ 16/juil./08 15:05 ] |
|
cvs ci src/com/babelstore/user/front/SellerModuleView.jsp dos2unix: converting file SellerModuleView.jsp to UNIX format ... Checking in src/com/babelstore/user/front/SellerModuleView.jsp; /home/cvs/dev/source/src/com/babelstore/user/front/SellerModuleView.jsp,v <-- SellerModuleView.jsp new revision: 1.11.4.1; previous revision: 1.11 done |
[cob] META-TACHE Fermeture cobs Mobilesachat, Free Surf, France Mobile, Midi Libre, Nice Matin
(APP-25098)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 52.0.0 (CTN-M) |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | Fabrice Feugas | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM: | *** RESERVE *** |
| Description |
|
Les cobs Mobilesachat, Free Surf, France Mobile, Midi Libre, Nice Matin seront inactifs à partir du 07/05/2009. Merci d'arrêter les rapports BI en même temps. |
| Commentaires |
| Commentaire de Cyril Tanneau [ 29/juin/09 12:40 ] |
|
Les rapports de cobrandings ont bien été arrêtés à la date spécifiée dans le Jira. merci, Cyril Tanneau |
| Commentaire de Christophe Garcia [ 29/juin/09 15:42 ] |
| MDPLVC |
| Commentaire de Cyril Tanneau [ 01/juil./09 12:25 ] |
|
Les rapports de cobrandings ont bien été arrêtés à la date spécifiée dans le Jira. merci, Cyril Tanneau |
[APP-32140] PEC : Suite au APP-32075, rattraper les comptes concernés... Création: 07/déc./10 19:07 Mise à jour: 07/déc./10 19:08 |
|
| Etat: | Ouvert |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Emeric Teil | Attribution: | Arnaud Forgues |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Pays: |
ALL - Tous
|
||||||||
| Projets PM: | *** CHASSE *** | ||||||||
| Description |
|
Comme vu ensemble, il faudrait essayer de rattraper
l'historique, en se basant sur l'évènement de création de compte contact
= Purchase et en changeant leur évènement de migration ?
NB : penser à voir le BI la dessus... |
[BIN-562] [Cobranding] : Membres Lycos Provence : réintégrer les données dans le flux PN_DATA Création: 27/févr./09 09:39 Mise à jour: 03/mars/09 14:10 Résolue: 03/mars/09 14:10 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Ghislain Gridel | Attribution: | Florian Ambrosi |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Les partenariats Lycos et La provence ont pris fin officiellement le 15/02/2009. Un email a été envoyé le 14/02 à tous les comptes pour leur dire qu'ils peuvent continuer à acheter sur PM L'équipe BI a déjà arrêté les rapports BI hebdo et mensuel le 16/02. MM les a déjà intégrés dans sa base CRM. Il reste à réintégrer les cobrandés --> réintégrer les données dans le flux PN_DATA : action BI, prochain envoi mensuel le 02/03. Sinon le 02/04. (validation juridique ok) Merci |
[EXP-2638] Passage massif de comptes en 1 Création: 13/sept./06 15:08 Mise à jour: 04/déc./07 11:38 Résolue: 04/déc./07 11:38 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Sébastien Mantanus | Attribution: | Patrick Pereira |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
tovalidate.csv.gz
upd_correctif_reliability.sql
upd_return_reliability.sql
|
||||||||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Description |
|
Comme vu avec Edouard, nous allons procéder à un passage
massif de comptes en 1, les conditions cont les mêmes que pour le
précédent passage avec des assouplissements, soit : - compte en 0 - compensation ok - connexion ok - PMV non bloqué - email ok - + de 50 ¿ achetés sur le compte - compte vieux de plus de 4 mois Merci |
| Commentaires |
| Commentaire de Antoine Koener [ 18/sept./06 09:19 ] |
|
Je te l'assigne car je ne sais pas quoi faire de ce JIRA. |
| Commentaire de Patrice Boulanger [ 20/sept./06 11:22 ] |
| Cette demande devient urgente. Edouard, merci de revenir vers moi pour qu'on voit ça ensemble aujourd'hui. |
| Commentaire de Edouard Laurent [ 20/sept./06 14:56 ] |
|
La requete va etre effectue par l'equipe decisionnelle Il faut envoyer a sebastien la liste des comptes qu'il va faire valider par PKM Ensuite je m'occuperais de faire l'update des comptes en prod Merci ! |
| Commentaire de Agathe Remy [ 20/oct./06 16:50 ] |
|
SELECT USER_ACCOUNT.USER_ACCOUNT_ID, USER_ACCOUNT.LOGIN FROM USER_ACCOUNT, PURCHASE, (SELECT DISTINCT BUYER_ACCOUNT_ID, MIN(AUTHORIZATION_DATE) AS FIRST_PURCHASE_DATE FROM PURCHASE WHERE PCH_STATUS_CODE NOT IN (10,20) GROUP BY BUYER_ACCOUNT_ID HAVING MIN(TO_CHAR(AUTHORIZATION_DATE,'YYYY/MM')) >= '2006-05' ) FIRST_PURCHASE WHERE USER_ACCOUNT.USER_ACCOUNT_ID=PURCHASE.BUYER_ACCOUNT_ID AND PURCHASE.BUYER_ACCOUNT_ID=FIRST_PURCHASE.BUYER_ACCOUNT_ID AND USER_ACCOUNT.GRANT_EMAIL = 1 AND -- email OK USER_ACCOUNT.GRANT_LOGIN = 1 AND -- connexion OK NVL(USER_ACCOUNT.IS_TO_VALIDATE, 0) = 0 AND -- compte en 0 USER_ACCOUNT.WLT_STATUS_CODE IN ( 10, 20 ) -- PMV non bloqué GROUP BY USER_ACCOUNT.USER_ACCOUNT_ID, USER_ACCOUNT.LOGIN HAVING SUM(toEuro2(NVL(PURCHASE.CAPTURE_CARD_AMOUNT,0) + NVL(PURCHASE.CAPTURE_OPERATION_AMOUNT,0) + NVL(PURCHASE.CAPTURE_COUPON_AMOUNT, 0), PURCHASE.CURRENCY_ID)) >= 50 |
| Commentaire de Edouard Laurent [ 20/oct./06 17:22 ] |
| Je dois faire quelquechose ? |
| Commentaire de Edouard Laurent [ 26/oct./06 16:34 ] |
| Je ferme ce JIRA ? ou il y a quelquechose a faire ? merci |
| Commentaire de Sébastien Mantanus [ 26/oct./06 16:48 ] |
| Ben il faudrait juste passer ces comptes en 1 et fermer le jira quand c'est fait; je reste à ta dispo si tu as besoin de plus d'infos |
| Commentaire de Sébastien Mantanus [ 27/oct./06 14:04 ] |
|
Le nombre de comptes est de 110 799 comptes. Je préfère qu'on attende le 8 novembre, date à laquelle Steven reviens pour le faire. |
| Commentaire de Edouard Laurent [ 27/oct./06 14:11 ] |
| Ok c'est note merci |
| Commentaire de Antoine Koener [ 16/nov./06 09:30 ] |
|
PriceJira étant arrété lorsqu'Edouard a récupéré le traitement, je poste en mon nom le commentaire qu'il m'a envoyé: apres avoir eu la validation de la part de Steven : J'ai executé la requete suivante sur titan : sqlplus babel_1/babel_1@GLOB.TITAN @ /data/priceminister/pmshare/exploit/edouard/bo_passage_massif_des_user_1.sql qui crée la table "tovalidate" qui contient la liste des user_account_id a passer en validation AUTO 1 Ensuite j'ai mis a jour la base de prod grace au script suivant : sqlplus babel_1/babel_1@GLOB.TITAN @ /data/priceminister/pmshare/exploit/edouard/passsage_1_OLTP.sql Suite au passage de ce dernier script j'ai teste un compte au hasard : "amphoux" et je me suis rendu compte qu'il ne rentrait pas dans les cirteres J'ai regarde plus en detail la requete de selection des donnees et je me suis rendu compte qu'il n'y avait pas de condition sur les compensations ce qui m'a semble bloquant J'avais au prealable fait un test sur TITAN. donc les donnees de titan sont corompus aussi Nous avons arrete avec Francois lelay l'alimentation de LATONE car c'est le seul endroit ou il y a encore les donnees correcte, nous avons verifie que le champ realibility etait bien mise a jour sur LATONE. Actuellement il y a donc des comptes en validation automatique sur la production qui ne devrait pas l'etre J'ai sauvegarde le contenu de la table "tovalidate" dans un dump "/data/priceminister/pmshare/exploit/edouard/tovalidate.dmp" |
| Commentaire de Patrice Boulanger [ 16/nov./06 11:47 ] |
|
Agathe, Peut-on extraire l'état des user_account_id avant le lancement du traitement d'Edouard afin de pouvoir les restaurer? L'idéal serait de voir avec Patrick les données dont il a besoin ainsi que le format du fichier. Merci. |
| Commentaire de Agathe Remy [ 16/nov./06 16:04 ] |
|
Patrick, Tu trouveras ci-joint le script de mise à jour des comptes qui n'auraient pas dus l'être. Il y a 601 comptes à mettre à jour. Cordialement, Agathe |
| Commentaire de Agathe Remy [ 16/nov./06 16:06 ] |
|
Pour info, Le problème n'était pas celui qu'on croyait:-) La condition de compensation est inutile dans la problématique "Validation Auto" qui ne concerne que les acheteurs. En revanche, la condition compte à 0 avait mal été interprétée et traduite par la condition is_to_validate=0 au lieu de reliability=0. Cordialement, Agathe |
| Commentaire de Agathe Remy [ 16/nov./06 17:19 ] |
|
Finalement nous faisons un retour arrière intégral!!! Voici le nouveau script de mise à jour avec un peu plus de 135992 lignes. Cordialement, Agathe |
| Commentaire de Agathe Remy [ 16/nov./06 17:29 ] |
|
Autre erreur : dans la condition de date, les formats ne sont pas les mêmes!!! De plus, nous voulons les comptes ayant effectué leur premier achat avant cette date et non après. Edouard, Voici la requête corrigée : SELECT USER_ACCOUNT.USER_ACCOUNT_ID, USER_ACCOUNT.LOGIN FROM USER_ACCOUNT, PURCHASE, (SELECT DISTINCT BUYER_ACCOUNT_ID, MIN(AUTHORIZATION_DATE) AS FIRST_PURCHASE_DATE FROM PURCHASE WHERE PCH_STATUS_CODE NOT IN (10,20) GROUP BY BUYER_ACCOUNT_ID HAVING MIN(AUTHORIZATION_DATE) < trunc(to_date('20060501','YYYYMMDD')) ) FIRST_PURCHASE WHERE USER_ACCOUNT.USER_ACCOUNT_ID=PURCHASE.BUYER_ACCOUNT_ID AND PURCHASE.BUYER_ACCOUNT_ID=FIRST_PURCHASE.BUYER_ACCOUNT_ID AND USER_ACCOUNT.GRANT_EMAIL = 1 AND -- email OK USER_ACCOUNT.GRANT_LOGIN = 1 AND -- connexion OK USER_ACCOUNT.RELIABILITY = 0 AND -- compte en 0 USER_ACCOUNT.WLT_STATUS_CODE IN ( 10, 20 ) -- PMV non bloqué GROUP BY USER_ACCOUNT.USER_ACCOUNT_ID, USER_ACCOUNT.LOGIN HAVING SUM(toEuro2(NVL(PURCHASE.CAPTURE_CARD_AMOUNT,0) + NVL(PURCHASE.CAPTURE_OPERATION_AMOUNT,0) + NVL(PURCHASE.CAPTURE_COUPON_AMOUNT, 0), PURCHASE.CURRENCY_ID)) >= 50 ; Cordialement, Agathe |
| Commentaire de Patrick Pereira [ 16/nov./06 18:26 ] |
| Je viens de lancer le script de retour arrière. |
| Commentaire de Patrick Pereira [ 16/nov./06 18:33 ] |
|
Le retour arrière est terminé. Je réassigne le JIRA à Edouard. |
| Commentaire de Antoine Koener [ 17/nov./06 09:59 ] |
|
Je ne saisis pas comment la requète du départ qui visiblement était incorrecte à pu être validée... Est-ce que cette nouvelle requète a été validée ? Est-ce que la méthode de validation à changée ? Ce sont peut être des points importants à eclaicir avant de repasser la requète non ? |
| Commentaire de Steven Harel [ 17/nov./06 10:08 ] |
|
une grille de tests est en cours de préparation avec l'équipe des fraudes les premiers tests n'étaient pas assez complets on avait bien pris une partie des comptes à passer en 1 et on a vérifié qu'ils matchaient les critères, ça c'est ok le souci est qu'on n'a pas pris de comptes en back office (qui ne matchaient pas au moins 1 critère), pour vérifier qu'ils ne se trouvaient pas dans la liste des comptes à passer en 1 nous allons vérifier rigoureusement le point 2 avec la prochaine grille de tests |
| Commentaire de Agathe Remy [ 17/nov./06 11:24 ] |
|
Pour info, avec la correction sur la condition de date, nous obtenons 434 969 comptes à mettre à jour. Cordialement, Agathe |
| Commentaire de Edouard Laurent [ 20/nov./06 10:00 ] |
| Je pense qu'il manque la condition sur : USER_ACCOUNT.USR_COMPENSATION_RIGHT_CODE |
| Commentaire de Sébastien Mantanus [ 23/nov./06 09:56 ] |
|
Voilà nous avons effectué tous les tests au niveau des
fraudes, dans les deux sens, Agathe, peux-tu envoyer la requête à
l'exploit pour qu'on puisse la faire passer au plus vite? car l'activité
commence à être importante et on risque d'être vraiment débordés si ça
ne passe pas vite... Merci ! |
| Commentaire de Agathe Remy [ 23/nov./06 12:41 ] |
|
SELECT DISTINCT USER_ACCOUNT_ID FROM USER_ACCOUNT, PURCHASE, (SELECT DISTINCT BUYER_ACCOUNT_ID, MIN(AUTHORIZATION_DATE) AS FIRST_PURCHASE_DATE FROM PURCHASE WHERE PCH_STATUS_CODE NOT IN (10,20) GROUP BY BUYER_ACCOUNT_ID HAVING MIN(AUTHORIZATION_DATE) < trunc(add_months(sysdate,-4)) ) FIRST_PURCHASE WHERE USER_ACCOUNT.USER_ACCOUNT_ID=PURCHASE.BUYER_ACCOUNT_ID AND PURCHASE.BUYER_ACCOUNT_ID=FIRST_PURCHASE.BUYER_ACCOUNT_ID AND USER_ACCOUNT.GRANT_EMAIL = 1 AND -- email OK USER_ACCOUNT.GRANT_LOGIN = 1 AND -- connexion OK USER_ACCOUNT.RELIABILITY = 0 AND -- compte en 0 USER_ACCOUNT.WLT_STATUS_CODE IN ( 10, 20 ) -- PMV non bloqué GROUP BY USER_ACCOUNT.USER_ACCOUNT_ID, USER_ACCOUNT.LOGIN HAVING SUM(toEuro2(NVL(PURCHASE.CAPTURE_CARD_AMOUNT,0) + NVL(PURCHASE.CAPTURE_OPERATION_AMOUNT,0) + NVL(PURCHASE.CAPTURE_COUPON_AMOUNT, 0), PURCHASE.CURRENCY_ID)) >= 50 ; Ce qui nous fait un total de 469 093 comptes à mettre à jour au 22/11/2006 minuit. |
| Commentaire de Sébastien Mantanus [ 23/nov./06 12:50 ] |
|
Merci de faire passer impérativement le batch avant demain,
pour des raisons de sécurité car on ne peut pas intervenir le W-E. Merci! |
| Commentaire de Edouard Laurent [ 27/nov./06 15:22 ] |
| Voici le fichier des comptes, merci de le valider, ensuite je pourrais proceder à la mise a jour |
| Commentaire de Sébastien Mantanus [ 27/nov./06 17:02 ] |
|
Les comptes de cette liste ont été testés, RAS, pour moi
tout est OK, j'ai noté certains points de contrôles (nbr cptes en -1 et
-2) pour comparer et re vérifier après. Vous pouvez faire passer. Merci |
| Commentaire de Edouard Laurent [ 27/nov./06 17:19 ] |
|
Voila c'est fait |
| Commentaire de Agathe Remy [ 28/nov./06 09:52 ] |
|
Bonjour Edouard, Pourrais-tu mettre à jour la change_date des enregistrements modifiés afin que ceux-vi soient automatiquement mis à jour dans le Datawarehouse cette nuit, stp? Merci:-) Agathe |
| Commentaire de Steven Harel [ 28/nov./06 15:41 ] |
|
peut-on automatiser cette tache ? genre toutes les semaines, plutôt milieu de semaine (nuit du mardi au mercredi) ça nous permettra de faire des vérifs tous les mercredis matin avec une seule variable pour les critères : les paniers (+ de 50 euros) ont été passés avant j-4 mois |
| Commentaire de Edouard Laurent [ 28/nov./06 16:42 ] |
| Voila c'est fait pour la demande d'Agathe |
| Commentaire de Edouard Laurent [ 04/déc./06 15:27 ] |
| Patrice qu'est ce que tu penses de la demande de Steven ? |
| Commentaire de Patrice Boulanger [ 04/déc./06 15:37 ] |
|
Je préférerai qu'on continue sur un mode manuel pendant
quelques temps surtout si on modifie les critéres de la requête. On
pourrait dire jusqu'à la fin de l'année. Ensuite, on automatise si aucun
problème n'est détecté. Je pense qu'il s'agit là d'un sujet
suffisamment sérieux pour qu'on ne se précipite pas. |
| Commentaire de Edouard Laurent [ 16/janv./07 10:22 ] |
|
Pour info : http://wikiexploit.lan:82/doku.php?id=edouard.laurent:projets:exploitation:passage_massif_des_compte_realibility_1 |
| Commentaire de Edouard Laurent [ 16/janv./07 10:36 ] |
|
Sebastien, Cela fait : 32 775 comptes qui vont etre passer en 1, tu valides ? Edouard |
| Commentaire de Sébastien Mantanus [ 16/janv./07 15:17 ] |
| Pour moi les résultats sont corrects. |
| Commentaire de Edouard Laurent [ 17/janv./07 15:20 ] |
|
J'ai refait un comptage pour etre sur : 33 299 ajourd'hui Est ce que tu peux refaire le comptage dans BO et me donner le chiffre que tu trouves ? merci Edouard |
| Commentaire de Sébastien Mantanus [ 17/janv./07 16:24 ] |
| 33 763 comptes pour moi... |
| Commentaire de Agathe Remy [ 17/janv./07 17:21 ] |
|
Votre différence est due à la condition "premier panier vieux de plus de 4 mois ". Dans le comptage d'ELA, on prend les comptes dont le premier panier est strictement inférieur à 4 mois. Dans le rapport BI de SMO, on prend les comptes dont le premier panier est inférieur ou égal à 4 mois. Agathe |
| Commentaire de Edouard Laurent [ 17/janv./07 18:23 ] |
|
Ouf j'arrive enfin au meme comptage que toi, cependant il
faut que l'on discute d'une condition encore, je reporte donc le passage
des comptes a 1 a la semaine prochaine ! |
| Commentaire de Edouard Laurent [ 22/janv./07 14:17 ] |
| voila le resultat de mon comptage : 36 585 , j'espere que l'on trouve la meme chose :~) |
| Commentaire de Sébastien Mantanus [ 22/janv./07 14:58 ] |
|
ok c'est bon de mon côté, meme résultat |
| Commentaire de Edouard Laurent [ 22/janv./07 15:20 ] |
| C'est bon j'ai passé les compte a 1, est ce que c'est toujours OK pour toi ? |
| Commentaire de Sébastien Mantanus [ 22/janv./07 16:30 ] |
| c'est toujours ok pour moi |
| Commentaire de Edouard Laurent [ 05/févr./07 15:24 ] |
| Cela fait 8468 comptes, c'est bon pour toi ? |
| Commentaire de Sébastien Mantanus [ 05/févr./07 15:34 ] |
|
c'est bon pour moi ! BI trouve 8491 ce qui est l'écart classique (comme vu la derniere fois) |
| Commentaire de Edouard Laurent [ 05/févr./07 15:42 ] |
|
Voila c'est fait, tu peux faire la verification des comptes en -1 et -2 Edouard |
| Commentaire de Edouard Laurent [ 16/avr./07 17:17 ] |
|
Voici la doc exploit qui permet de mettre a jour les comptes : http://wikiexploit.lan:82/doku.php?id=edouard.laurent:projets:exploitation:passage_massif_des_compte_realibility_1 Cette demande est traitée |
| Commentaire de Cedric Favero [ 12/juin/07 17:55 ] |
|
Il est toujours nécessaire d'effectuer cette tache regulièrement pour soulager le travail des fraudes. Sebastien Mantanus étant parti , c'est moi qui vais gérer la validation des fichiers résultant de ces opérations. Qui peut reprendre le process à l'exploitation dans l'attente d'une possibile automatisation du processus? |
| Commentaire de Justin Ziegler [ 08/août/07 16:51 ] |
|
Steven, est ce que tu pourrais stp passer 5 minutes a documenter ce jira ? Pourquoi fait on cela ? A quoi ca sert ? Faut il changer l'appli pour éviter d'avoir à faire cela ? |
| Commentaire de Cedric Favero [ 29/août/07 17:55 ] |
|
Je n'avais pas reçu le commentaire de justin et retombe donc dessus en venant voir ce qu'il en est. Celà est tjrs d'actualité pour exclure des règles d'observation un grand nombre de comptes jugés fiables... Steven,tu vois s'il faut qu'on en reparle... ? |
| Commentaire de Steven Harel [ 30/août/07 10:17 ] |
|
pas vu le commentaire de justin cédric s'occupe de suivre ce truc (doc, vérifs, ...) avec sebastien bruzzone son client |
| Commentaire de Justin Ziegler [ 03/sept./07 15:41 ] |
|
cela nous éclarie pas franchement bcp comme doc :-) on ferme le jira alors ? |
| Commentaire de Cedric Favero [ 03/sept./07 15:49 ] |
|
Je peux prendre un moment pour vous expliquer le truc mais on est sous l'eau ces jours-ci... Tu prefères l'avoir dans le JIRA on peut prendre 10min pour en discuter? |
| Commentaire de Justin Ziegler [ 03/sept./07 16:07 ] |
| si le jira doit rester ouvert, il vaut mieux mettre un peu d'explication dans le jira je pense. Comme cela tout ceux qui sont concerné en profiteront. |
| Commentaire de Cedric Favero [ 04/sept./07 14:56 ] |
|
Alors, je détaille donc un peu la demande: L'équipe des fraudes (Sebastien Bruzzone) valide chaque jour manuellement des centaines de paniers qui ont été placés en observation selon diverses règles gérées par des mots clés en code velocity,ceci afin de detecter en amont de possibles achats frauduleux et ainsi minimiser au maximum les risques d'opposition. Ces reglès d'observation fonctionnent par palliers (montants) mais aussi par exclusion ( par exemple panier de plus de 200 euros sauf si pro , sauf si payé par porte-monnaie , etc...) ex: d'un mot clé velocity placant un panier en observation pour un montant superieur à 200¿: ! $userConstants.RELIABILITY_HIGH.equals($buyer.reliability) && ! $buyer.isPro() && ! $purchase.isECarteBleue() && ! $purchase.useWallet() && ! $purchase.useCoupon() && ! $purchase.isNego() && $util.greaterThan($stats.Amount24H, 200) && $util.lessThan($stats.Amount24H, 301) Une des variables très importante dans ce process est le $buyer.reliability puisqu'on exclue de nos premiers palliers de surveillance tous les comptes étant jugés "fiables" , c'est à dire étant en validation auto = 1 , selon les critères définis dans ce JIRA et le Wiki documenté par Edouard Laurent. Le nombre de paniers placés en observation étant en permanence très important et en particulier les week-ends , il est crucial d'exclure de ces regles les paniers effectués par des comptes considérés comme fiables afin que : -d'une part , ils soient validés automatiquement et non mis inutilement à l'état "réservé" pendant plusieurs jours -d'autre part soit allégé le travail de validation manuelle des paniers par l'équipe des Fraudes , pouvant se concentrer sur des paniers mis en observation plus pertinemment. En gros , ce process passe donc les comptes matchant les critères requis en validation auto 1 afin que leurs paniers ne tombent plus en observation inutilement. J'espère avoir été assez clair et suis dispo pour toutes précisions. |
| Commentaire de Justin Ziegler [ 04/sept./07 17:13 ] |
|
Merci pour ces explications tres claires. Il manque juste un point concernant le process : 1/ vous demandez régulièrement à l'exploit de faire une manip prédéfinie par l'intermédiaire de ce jira ? 2/ vous laissez le jira pour qu'ils n'oublient pas de le faire, tout seul ? 3/ c'est exactement la meme manip a chaque fois ? |
| Commentaire de Steven Harel [ 04/sept./07 18:01 ] |
|
la manip est toujours la même il serai pas-mal de pouvoir l'automatiser (genre routine de suppression de fiches à stock 0 avec émission d'un fichier, tests par cédric et validation) |
| Commentaire de Cedric Favero [ 04/sept./07 18:07 ] |
|
Il était question de l'automatiser mais je pense que dans
l'immédiat il est plus raisonnable de le faire ponctuellement par
l'intermédiaire de ce JIRA , le temps de s'assurer que celà est bien
rodé et que l'objectif visé est accompli sans erreurs. Le dernier passage étant assez ancien , il doit y avoir un nombre importants de comptes concernés et une vérification attentive est donc nécessaire (on a une procédure de test pour çà , il faut que s'assurer que tout est toujours ok). A priori la requete serait toujours la meme si les tests s'avèrent positifs , il faut juste garder un controle manuel à chaque fois (c'est moi qui m'en chargerais en l'occurence..). L'idéal serait donc que je puisse avoir un fichier provenant de la requete documentée dans le Wiki afin que je puisse travailler dessus et vérifier qu'elle est correcte. Merci. |
| Commentaire de Agathe Remy [ 04/sept./07 18:21 ] |
|
Normalement, il existe un rapports BusinessObjects développé
à l'époque pour Sébatien Montanus qui lui permettait d'extraire les
informations nécessaires au contrôle sur la même cible que la requête de
mise à jour de l'exploitation. Pour une reprise en confiance, je pense qu'une vérification avec l'exploitation que c'est toujours le cas ne fera pas de mal. Agathe |
| Commentaire de Cedric Favero [ 25/sept./07 15:11 ] |
|
Agathe saurais tu me dire le rapport en question afin que je
me penche un peu sur BusinessObjects par la meme occasion? Une fois que je suis opérationnel de mon coté , on relance le process avec l'exploitation. Merci. |
| Commentaire de Cedric Favero [ 10/oct./07 14:45 ] |
|
C'est bon vu avec Agathe pour l'utilisation du rapport Business Objects. 151 377 comptes matchant les paramètres requis sont à traiter pour passer en validation auto 1 (reliability = 1) Il me faut donc qqun à l'exploit pour lancer la requete et que l'on puisse comparer les résultats avant chaque passage du batch. Bossant déjà avec Eric Vannier sur les problématiques de contrefaçon , je suggère de faire çà avec lui. Patrice je te laisse assigner le JIRA à la personne la plus adaptée... |
| Commentaire de Cedric Favero [ 14/nov./07 09:42 ] |
|
Ca fait plus d'un mois que j'attend un retour sur ce JIRA... L'idée était de faire passer ce batch avant la période forte de Noel mais on est déjà en plein de temps... Le nombre de paniers explose , il faut vraiment qu'on puisse soulager l'équipe des Fraudes pour qu'elle puisse travailler dans de bonnes conditions. Qui plus est , la requete existant déjà, il s'agit simplement de comparer les résultats de la requete avec mon rapport Business Objects pour s'assurer que les chiffres correspondent . |
| Commentaire de Cedric Favero [ 14/nov./07 10:19 ] |
| j'ai 175 000 comptes en attente à ce jour , il y a vraiment urgence. |
| Commentaire de Patrick Pereira [ 14/nov./07 11:58 ] |
| J'ai lancé la requête de comptage. Je te tiens au courant. |
| Commentaire de Patrick Pereira [ 14/nov./07 14:29 ] |
|
Tu peux trouver le fichier contenant les user_account_id à l'emplacement suivant : W:\pereira\list_user_account_20071114.txt.gz Il contient 177470 utilisateurs. Dis-moi si c'est ok. |
| Commentaire de Cedric Favero [ 14/nov./07 14:54 ] |
|
J'ai 175 007 comptes à ce jour dans mon rapport BI Agathe, Par rapport à ce que tu disais: "Dans le comptage d'ELA, on prend les comptes dont le premier panier est strictement inférieur à 4 mois. Dans le rapport BI de SMO, on prend les comptes dont le premier panier est inférieur ou égal à 4 mois. " Celà te semble-il pouvoir expliquer l'écart de 2000 comptes? |
| Commentaire de Cedric Favero [ 14/nov./07 15:07 ] |
|
En fait j'en ai 174205 si je fais wallet_status_code 10 ou 20 (non activé et activé) Car j'avais pour ma part spécifié wallet_status_code different de 40 (bloqué) En fait la requete pourrait dire USER_ACCOUNT.WLT_STATUS_CODE IN ( 10, 20,30 ) mais c'est un détail. (30 correspondant au statut "restreint") |
| Commentaire de Agathe Remy [ 14/nov./07 16:11 ] |
|
Patrick, Peux-tu voir avec Cédric pourquoi vous n'obtenez pas la même chose? Je pense qu'il faut comparer la requête BI et celle que vous utilisez. Je peux te montrer comment accéder à la requête BI?! Merci:-) Agathe |
| Commentaire de Cedric Favero [ 14/nov./07 17:17 ] |
|
Bon ,vu avec Agathe , les deux requetes sont bonnes et correspondent. La différence peut etre due à la date de premier panier dans BI mais rien de bloquant pour le passage du batch réellement urgent. J'ai fait pour ma part des tests croisés: comptes en -1 , -2 , pmv bloqués..etc pour m'assurer qu'ils n'étaient pas repris par la requete et tout est ok. Patrick , dis moi quand le batch peut passer , le plus tot étant le mieux , en evitant les fins de semaine evidemment...(semaine prochaine?) Merci. |
| Commentaire de Patrick Pereira [ 15/nov./07 12:47 ] |
|
Le traitement est passé. Dites-moi si c'est ok. |
| Commentaire de Steven Harel [ 15/nov./07 13:07 ] |
|
super, merci beaucoup ça nous sauve, cédric fait des vérifs pour voir si tout s'est bien passé prochaine étape : l'automatisation du batch :) |
| Commentaire de Cedric Favero [ 15/nov./07 15:06 ] |
|
Genial. Merci d'avoir fait passer ce traitement en urgence. J'ai repris mes comptes tests et les -2 , les -1 , les bloqués, etc.. sont bien restés à leur place. Les comptes matchant les critères ont bien été passés en 1. Une bonne chose de faite donc. Concernant l'automatisation , je pense qu'il n'est pas nécessaire de le faire chaque semaine , un passage mensuel étant suffisant. On pourrait par exemple programmer l'exécution tous les premiers mardi du mois... Merci de m'indiquer en fonction des disponibilités de la base et autres considérations techniques à quelle date on pourrait le fixer afin que je synchronise l'éxecution de mon rapport Business Objects de mon coté. Si je propose le mardi , c'est pour une logique comme suit: -eviter le lundi -reception des resultats de la requete par mail le mardi. -vérification et tests de ma part pour confirmation -passage du batch le jeudi C'est une proposition,on en parle quand vous voulez pour les modalités. Merci d'avance. |
| Commentaire de Patrick Pereira [ 20/nov./07 12:03 ] |
|
Ca me va. J'ai mis en place le traitement automatique qui s'exécute tous les premiers mardi de chaque mois et qui t'envoie par mail la liste de user_account_id à migrer. Voyons le 4 décembre le résultat. |
| Commentaire de Cedric Favero [ 20/nov./07 12:07 ] |
| Ok super. Merci. |
| Commentaire de Cedric Favero [ 04/déc./07 11:38 ] |
|
Vu avec Patrick , le process est en place, je ferme donc le JIRA. Chaque premier mardi du mois , le resultats de la requete me sont envoyés. Je lui donne mon retour par mail après vérifications et il me confirme le traitement des comptes. |
[BIN-629] [Back Office] : ajouter le "droit de réponse vendeur" à l'univers item Création: 23/sept./09 17:03 Mise à jour: 16/mars/10 15:54 Résolue: 23/oct./09 10:12 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | BackOffice |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Steven Harel | Attribution: | Dalila Belkebir |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Extract des reponses vendeurs le 01 10 2009.xlsx
|
| Pays: |
ALL - Tous
|
| Description |
|
nous allons avoir besoin de suivre la nouvelle fonctionnalité "droit de réponse". on aimerait donc avoir, dans l'univers item, les commentaires des vendeurs aux notes des acheteurs. |
| Commentaires |
| Commentaire de Dalila Belkebir [ 23/sept./09 17:08 ] |
|
Bonjour Steven, Le projet de refonte Q/R est prévu pour novembre 2009. A ce jour nous ne disposons pas des données Q/R dans le BI. Nous comptons les intégrer au moment de la MEP en novembre. Je te propose de revenir vers toi dès que les KPI du projet et son implémentation seront définis. Cordialement, Dalila. |
| Commentaire de Steven Harel [ 23/sept./09 17:34 ] |
|
hi ! on ne parle pas de q/r mais du nouveau droit de réponse. c'est quand un acheteur met 1/5 au vendeur en laissant "escroc" en commentaire de cette note. le vendeur peut "commenter" (ce n'est pas un message) la note de l'acheteur en disant "toi-même". c'est visible sur la page des notes du vendeur dans sa boutique. rien à voir avec le q/r si ? |
| Commentaire de Dalila Belkebir [ 23/sept./09 17:53 ] |
|
Okayyyyyy Effectivement rien à voir avec Q/R ... Désolée de ma première réponse trop spontanée et motivée :-) Effectivement il y a bien un nouveau champ ds la base "SELLER_SCORE_FEEDBACK", nouveau champ que nous n'avons pas dans le BI. => Il nous faut donc récupérer la donnée dans l'alimentation avant de la mettre à dispo dans l'Univers. Donc un peu couteux pour nous. Comment souhaites-tu la suivre ? de manière assez régulière ou ponctuelle ? dans un rapport ou une extraction de données ? Dalila. |
| Commentaire de Steven Harel [ 29/sept./09 11:39 ] |
| a priori de manière ponctuelle pour voir comment c'est utilisé. pas vraiment de rapport prévu par la suite |
| Commentaire de Dalila Belkebir [ 01/oct./09 17:41 ] |
|
Steven, Comme vu ensemble : d'abord un extract de données, ensuite on évalue le besoin. Voici une répartition du nombre de réponses vendeur par note : Nb d'item Nb de réponses vendeur Note du vendeur 14 161 / 524 / 0 253 027 / 906 / 1 210 635 / 702 / 2 572 530 1 / 274 / 3 2 253 462 / 1 750 / 4 16 869 084 / 3 317 / 5 Il y a en tout 7 800 réponses vendeurs max. D'où ma volonté d'attendre afin d'éventuellement remonter les infos ds le BI. Tu trouveras également ci-jointe une extraction de données. je te laisse regarder ces données. Si tu as besoin d'autre infos, n'hésites pas ! Cdlt, dalila. |
| Commentaire de Dalila Belkebir [ 01/oct./09 17:42 ] |
|
Pour un usage ultérieur, la requête d'extraction est dans
T:\BI\01 - Demandes ponctuelles\03 - Back Office\Extract des réponses
vendeurs. Dalila. |
| Commentaire de Dalila Belkebir [ 23/oct./09 10:12 ] |
|
Steven, As-tu eu le temps de regarder l'extract ? Cdlt, Dalila. |
| Commentaire de Steven Harel [ 27/oct./09 16:36 ] |
|
hello, merci pour ces infos. j'ai 80 lignes en tout dans le doc. c'est le bon format mais pas assez d'infos pour pouvoir se faire une idée de l'utilisation. est-ce qu'on peut programmer un nouvel extract de tous les commentaires vendeurs genre dans 10 jours. ça devrait nous permettre de voir comment c'est utilisé et modifier nos mots-clé en conséquence. merci bcp |
| Commentaire de Dalila Belkebir [ 27/oct./09 18:34 ] |
|
Hello Steven, Je viens de refaire un extract ... je pense que tu vas avoir suffisamment d'infos à nalayser maintenant. Le fichier est gros, il est dans le répertoire : T:\BI\01 - Demandes ponctuelles\03 - Back Office\Extract des réponses vendeurs Cdlt, Dalila. |
| Commentaire de Steven Harel [ 05/nov./09 08:56 ] |
| merci ! je vais voir ça. |
[APP-5203] Messagerie : problème boîte "back garantie auto" dans messagerie Création: 06/juil./05 18:06 Mise à jour: 25/juin/07 18:30 Résolue: 07/juil./05 15:28 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 8.0.2g |
| Version(s) corrigée(s): | 8.0.3 |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Charlotte Fachan | Attribution: | Geneviève Beaujard |
| Résolution: | Impossible à reproduire | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
dans la messagerie (pour ex boîte back question ach"),
lorsqu'on veut transférer un message par le biais du lien "déplacer
vers" ...."garantie auto", cela ne marche pas. Le mail reste dans la
boîte initiale.
|
| Commentaires |
| Commentaire de Geneviève Beaujard [ 07/juil./05 15:28 ] |
| jemina me dit que charlotte a du faire une erreur de manip |
[EXP-2706] PB de mémoire Création: 25/sept./06 16:09 Mise à jour: 25/juin/07 18:59 Résolue: 10/oct./06 08:59 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Samir Beghdadi | Attribution: | ZZ_Arnaud Baali |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Salut Arnaud, Il serait génial d'augmenter la RAM de mon pc qui n'arrive plus à suivre mais grave, depuis que j'utilise à la fois les deux applications du BI (BO et OWB) qui sont très gourmandes en mémoire. Merci bcp |
[DEC-576] rapport mev + SLTV Création: 02/avr./07 10:00 Mise à jour: 14/sept./07 15:31 Résolue: 10/avr./07 19:19 |
|
| Etat: | Fermé |
| Projet: | Reporting |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Thomas Beylot | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
hello début de mois oblige, voilà le traditionnel jira pour demander les rapports de mise en vente et SLTV (pas besoin de générer les rapports de populations puisqu'un jira y référant explique que pour l'instant ils sont biaisés, en attendant réparation) merci |
[BIN-340] [Affiliation] : Optimisation du rapport Affiliation Achat Création: 05/juin/07 19:59 Mise à jour: 14/sept./07 18:04 Résolue: 01/août/07 17:30 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Ghislain Gridel | Attribution: | Samir Beghdadi |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Sur BI, le rapport Affiliation de validation des achats marche difficilement. Le temps de réponse est extrémement long. est-il possible de trouver des pistes d'optimisation, svp ? Merci. Ghislain |
| Commentaires |
| Commentaire de Romain Czornomaz [ 13/juin/07 11:02 ] |
|
Samir, Afin d'améliorer la génération du rapport PriceMinister - Affiliation purchase checking, il faut optimiser la requete qui est effectué sur l'univers ITEM. Pour cela, il faut créer une dénormialisation de purchase tracking dans la table ITEM. voici les taches à effectuer: - Modification de la table TF_ITEM pour ajouter les champs PCH_TRACKING_ID et PCH_TRACKING_DATE - Modification des alimentations FULL / DAILY pour prendre en compte l'alimentation de ces champs - Modification de l'univers ITEM pour ajouter la jointure de PCH_TRACKING_ID vers TRACKING -> TRACKING_GROUP - Ajout dans l'univers ITEM de la classe PURCHASE TRACKING avec les objets suivants: objets de type dimension sur PCH TRACKING ID, PCH TRACKING NAME, PCH TRACKING GROUP ID, PCH TRACKING GROUP NAME, PCH TRACKING DATE et les filtres de type invites utilisateurs "Select purchase tracking group" et "Select purchase tracking" - Modification du rapport pour ajouter l'invite utilisateur "Select purchase tracking group" dans la requete ITEM. Romain |
[BIN-384] rapport bilan coupon par mois Création: 18/oct./07 10:27 Mise à jour: 09/nov./07 17:51 Résolue: 29/oct./07 15:21 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Olivier Mathiot | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
le rapport bilan coupon par mois plante tous les mois et en plus il tourne pendant des heures nous avons bcp de mal à suivre l'évolution de ce budget... qui repésente 90 000¿ par mois et qui a explosé de puis 2 mois est il possible de l'optimiser ??? dasn le repértoire BI d'odile |
| Commentaires |
| Commentaire de Agathe Remy [ 29/oct./07 15:21 ] |
|
Pour mémo technique : Remplacement de l'index FK_PCH_COUPON sur la table TF_PURCHASE par un index bitmap. Comme il y a beaucoup de valeurs nulles, l'optimisation obtenues est spéctaculaire:-) Agathe |
Installation du serveur de développement utilisant la dernière version de la stack Redhat/JBOSS (STUART)
(INF-8)
|
|
| Etat: | Résolu |
| Projet: | Infrastructure |
| Composants: | Réseau |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | Patrice Boulanger | Attribution: | Stéphane Eccli |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Le serveur sera l'un des serveurs 1950 qui n'est pas encore utilisé. - Bi-proc/Dual core - 16 Go de RAM mini - 2x146Go en RAID 1 A racker dans la baie n° 7 (celle à fond à droite en entrant). |
| Commentaires |
| Commentaire de Stéphane Eccli [ 14/avr./08 18:29 ] |
| serveur racké |
[EXP-4621] Installation de MS Project sur mon poste depuis le poste de Florian Création: 18/nov./08 18:44 Mise à jour: 19/nov./08 16:22 Résolue: 19/nov./08 16:22 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Installation |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Bloquant |
| Rapporteur: | Dalila Belkebir | Attribution: | Stéphane Eccli |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
J'avais MS Project mon ancien poste occupé maintenant par Florian. Peux-tu STP récupérer MSP du poste de Florian et l'installer sur mon poste ? Sinon je ne peux pas mettre à jour le planning BI pour demain :-) Merci. Dalila. |
| Commentaires |
| Commentaire de Stéphane Eccli [ 19/nov./08 16:22 ] |
| ok |
[BIN-598] [Sales] : Création des conditions prédéfinies "Last 7 user event days" et "Last user event month" Création: 23/juin/09 18:31 Mise à jour: 08/juil./09 19:17 Résolue: 08/juil./09 19:17 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Sales |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Dorian Porta Delsol | Attribution: | Geoffroy Vigneron |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Hello la BI team , Pourriez vous créer ces 2 nouveaux indicateurs : "Last 7 user event days" "Last user event month" Dans FRANCE - USER EVENT en priorité. Puis ES et UK par la suite. Merci :-) |
| Commentaires |
| Commentaire de Cyril Tanneau [ 06/juil./09 18:16 ] |
|
Bonjour Dorian, pour répondre à ta demande, nous avons créé les filtres: - "Last 7 user event days" dans la classe User event creation date hierarchy de l'univers User event - "Previous user event month" dans la classe User event creation date hierarchy du même univers. Ces filtres sont disponibles pour les plateformes FR, ES et UK. Peux-tu les valider? Merci, Cyril |
| Commentaire de Dorian Porta Delsol [ 07/juil./09 15:17 ] |
|
C'est parfait ! Tout roule ! Merci |
[EXP-5077] Identification des comptes professionnels avec FTP Création: 25/mars/10 10:24 Mise à jour: 25/mars/10 10:24 |
|
| Etat: | Ouvert |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Dorian Porta Delsol | Attribution: | Patrice Boulanger |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Est il possible de mettre un indice d'identification pour
les professionnels disposant de compte FTP pour pouvoir les faire
ressortir dans BI ? L'idéal serait des marqueurs différents pour les flux de commandes et les flux d'import de stock. Merci |
Etude de mise en oeuvre d'une stratégie de sauvegarde des plateformes internes
(EXP-753)
|
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Etude |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Sous-tâche | Priorité: | Critique |
| Rapporteur: | Alain Bonneaud | Attribution: | Pap Ndiaye |
| Résolution: | Corrigé | ||
| Estimation restante: | 0 minutes | ||
| Temps consacré: | 2 heures | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Etude des données présentes sur les plateformes internes et
des volumétries correspondantes (plateforme système, serveurs
utilitaires, serveurs BI, environnements de développement, d'intégration
et de préproduction, ...) ainsi que des évolution envisagées pour
l'année 2006
|
| Commentaires |
| Commentaire de Pap Ndiaye [ 12/janv./06 11:31 ] |
| Je t'ai envoyé un mail récapitulatif des données sauvegardé actuellement et la capacité total de tous nos serveurs. |
[EXP-753] Etude de mise en oeuvre d'une stratégie de sauvegarde des plateformes internes Création: 03/janv./06 19:14 Mise à jour: 25/juin/07 18:55 Résolue: 29/sept./06 13:56 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Etude |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Alain Bonneaud | Attribution: | Patrice Boulanger |
| Résolution: | Corrigé | ||
| Σ Estimation restante: | 0 minutes | Estimation restante: | Non spécifié |
| Σ Temps consacré: | 2 heures | Temps consacré: | Non spécifié |
| Σ Estimation originale: | Non spécifié | Estimation originale: | Non spécifié |
| Sous-tâches: |
|
| Description |
|
Etude préalable à la mise en oeuvre d'une stratégie de
sauvegarde sur les plateformes internes (plateformes systèmes, serveurs
utilitaires, serveurs BI, serveurs de développement, environnements
d'intégration, environnements de préproduction)
|
| Commentaires |
| Commentaire de Patrice Boulanger [ 29/sept./06 13:56 ] |
|
Nouveau JIRA: |
[BIN-207] nb de paniers sur le mail PMV créditrés non activés Création: 26/oct./06 10:37 Mise à jour: 14/sept./07 17:30 Résolue: 30/oct./06 19:15 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Alexandra Viravaud | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Salut Mohamed, je souhaiterais connaitre le nb de paniers générés par le tracking 1366040 chaque mois. Est-ce que je peux retrouver cette information à partir d'un des rapports existants sur BI? Merci Alexandra |
| Commentaires |
| Commentaire de Agathe Remy [ 30/oct./06 19:15 ] |
| Tu devrais trouver cette information dans le rapport Dossiers publics/Marketing/Purchase/Purchase by month. |
[APP-16367] Articles n'apparaissant pas dans "recyclez vos achats" Création: 15/mai/07 12:29 Mise à jour: 06/juil./07 17:46 Résolue: 05/juin/07 14:44 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Recyclage |
| Affecte la/les version(s): | 14.0.1 |
| Version(s) corrigée(s): | 15.0.0 |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Cedric Favero | Attribution: | Geneviève Beaujard |
| Résolution: | Invalid | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM: | *** RESERVE *** |
| Classif1: | MON COMPTE |
| Classif2: | recyclage |
| Description |
|
Pseudo: pgbg Cette personne a déjà acheté 5 articles mais seuls 2 sont présents lorsqu'elle clique sur "recyclez vos achats" Elle veut en particulier revendre l'article "Creative Zen Micro - Batterie" par ce biais mais l'article n'apparait pas (délai?) |
| Commentaires |
| Commentaire de Younès Charrière [ 15/mai/07 14:49 ] |
|
Vu avec Renaud il y a plusieurs conditions à réunir pour pouvoir recycler ses achats : private void prepareItemRecycleByBuyerSQL(Long lBuyerAccountId) { setFrom("item, product"); addWhere("item.product_id = product.product_id"); addWhereConst("product.prd_status_code IN (?)", new Long[] {PrdStatusCode.VALIDATED_BO,PrdStatusCode.VALIDATED_SYS,PrdStatusCode.PURGED}); addWhere("item.buyer_account_id = ?", lBuyerAccountId); addWhereConst("item.itm_status_code = ?", ItmStatusCode.CLOSED); addWhereConst("item.seller_score >= ?", new Long(3)); // Note >= 3 addWhere("item.is_abandonned IS NULL"); // Article a été acheté addWhere("NOT EXISTS (" + getProductSQL() + ")"); // Condition pour s'assurer que l'acheteur n'a pas déjà remis en vente l'article } Donc en résumé si je comprend bien il faut que l'article soit bien acheté, qu'il ait eu une note supérieure ou égale à 3 lors de l'achat, qu'il est en état CLOSED et que le produit auquel est rattaché l'annonce soit Validé par le BO ou bien par le système ou bien purgé, ... et d'autres obscures raisons :) La personne décrite par Cédric a acheté 4 articles et non 5 (un a été refusé par le vendeur) et actuellement il peut recycler 3 de ses articles. Il y en a un par contre noté 3 qui rempli à priori les conditions ci-dessus mais qui n'est pas encore recyclable. J'aurais donc besoin d'un oeil éclairé sur la question : http://bo.pm.lan/purchase_back?action=itemview&itemid=35867351&purchaseid=30985477 Merci. |
| Commentaire de Geneviève Beaujard [ 05/juin/07 14:42 ] |
|
Petite precision: addWhere("item.is_abandonned IS NULL"); il n'a pas eu de claim acceptée sur cet item. Cedric et moi avons controlé les regles et nous sommes d'accord sur le resultat obtenu. |
| Commentaire de Younès Charrière [ 06/juil./07 17:46 ] |
| Ok alors je ferme le jira. |
[APP-23066] Provenance : à mettre en place pour le UK Création: 13/nov./08 09:58 Mise à jour: 19/déc./08 17:59 Résolue: 25/nov./08 14:42 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 33.0.0 (CAT-E) |
| Version(s) corrigée(s): | 37.0.0 (TX-D) |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Charles Decaux | Attribution: | Clement Balay |
| Résolution: | Doublon | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Pays: |
GBR - Royaume Uni, FRA - France
|
||||||||
| Site: | Prod | ||||||||
| Projets PM archivés: | UK - Plateforme BETA | ||||||||
| Description |
|
Afin de générer du trafic de la France vers le UK, je
souhaite mettre en place une version de "provenance" qui permet à
l'utilisateur anglais sur PM FR d'aller sur PM UK par le biais de
l'affichage d'un layer merci |
| Commentaires |
| Commentaire de Emeric Teil [ 25/nov./08 11:44 ] |
|
Clément, il me semble qu'on peut fermer cette demande non ?
(si c'est le cas, merci d'attacher le Jira traitant de cela). |
| Commentaire de Clement Balay [ 25/nov./08 14:42 ] |
| Oui, effectivement, on avait déjà traité la demande |
[IMP-7709] SOLDES > POUR MISE A JOUR RAPIDE DES PRIX D'ORIGINE ET DE VENTE > Création format + profil > fashion > MILO-78 Création: 27/déc./10 10:51 Mise à jour: 29/déc./10 10:43 Résolue: 29/déc./10 10:43 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Demande commerciale |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Isabelle Weisbecker | Attribution: | Jérome Marianne |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Login: | MILO-78 |
| Modèle: | fashion |
| Séparateur: | Point-virgule (;) |
| Type de traitement: |
Mise à jour/création annonces avec mise à jour/création produits (écrasement) , Mise à jour/création annonces avec mise à jour/création produits
|
| Description |
|
en préparation des Soldes, créer format et profil.
Je procéderai moi-même à l'extarction de l'inventaire sur BI et ferai le fichier d'import pour un taux d'import à 100% de réussite. Créer 2 types de traitement : entrée et écrasement |
| Commentaires |
| Commentaire de Jérome Marianne [ 27/déc./10 17:19 ] |
| C'est le format type fashion qui doit être paramétré ou un format spécifique lié à l'extraction? |
| Commentaire de Isabelle Weisbecker [ 28/déc./10 10:40 ] |
| merci de crer le format "fashion" |
| Commentaire de Jérome Marianne [ 29/déc./10 10:43 ] |
|
Les profils "Entrée/Sortie" et "Écrasement" ont été paramétrés avec le format de base "Fashion".
|
[APP-32515] Formulaires de contact pour vendeurs pros HS Création: 19/janv./11 18:15 Mise à jour: 20/janv./11 16:20 Résolue: 20/janv./11 15:35 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aide en ligne |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 84.0.1.2 |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Habib-Sylvain Gourguet | Attribution: | Habib-Sylvain Gourguet |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
screenshot-1.jpg
screenshot-2.jpg
|
||||||||
| Liens des demandes: |
|
||||||||
| Pays: |
ALL - Tous
|
||||||||
| Projets PM: | *** A PLANIFIER *** | ||||||||
| Description |
|
Voir dans la FAQ.
Le noeud "Je suis un vendeur professionnel" s'ouvrait auparavant sur une quinzaine de formulaires de contact. Ceux-ci sont aujourd'hui inaccessibles et il est devenu impossible de contacter l'équipe commerciale par ce biais. |
| Commentaires |
| Commentaire de Habib-Sylvain Gourguet [ 19/janv./11 18:23 ] |
|
Vu avec Espérance (merci !). Il est envisageable de publier
une v84.0.1.2 rapidement avant le début de l'integ de la v85.
Le bug vient du fait que l'équipe Edito SAV travaille actuellement à la mise en place d'une "FAQ pros" et à la réorganisation des infos dispos dans le noeud en question. On souhaitait notamment supprimer la quinzaine de formulaires de contact pour n'en garder qu'un seul. Problème : la suppression d'une structure n'a pas besoin de respecter le process de publication habituel pour être effective (mea culpa). @Gaël : on va profiter de l'occasion pour ne garder qu'un formulaire de contact à destination de l'équipe commerciale. On voit ça ensemble asap. |
| Commentaire de Gaël Seguillon [ 19/janv./11 18:33 ] |
|
Merci Habib
@Esperance STP absolument cette semaine, les pros ne peuvent plus nous contacter, il faut vraiment pouvoir remettre le lien vers la boite de messagerie le plus vite possible merci Gaël |
| Commentaire de Habib-Sylvain Gourguet [ 20/janv./11 11:08 ] |
|
A publier sur REF et BRANCH pour FR (à traduire sur ES/UK) :
/online_help/Help Articles/Folder02 - FAQ/Contact/Folder06 - Je suis un vendeur professionnel/01 - Contact (équipe commerciale) |
| Commentaire de Habib-Sylvain Gourguet [ 20/janv./11 11:29 ] |
|
/online_help/Help Forms/Folder Vendeur PRO/Contact équipe commerciale (PROD ADMIN CO/Messagerie)
/ONLINE_HELP/CONTACT /ONLINE_HELP/CONTACT/VOUS_ETES_UN_VENDEUR_PROFESSIONNEL /ONLINE_HELP/CONTACT/VOUS_ETES_UN_VENDEUR_PROFESSIONNEL/CONTACT_EQUIPE_COMMERCIALE |
| Commentaire de Pablo Anton [ 20/janv./11 11:47 ] |
|
Publié sur REF - ES
/online_help/Help Articles/Folder02 - FAQ/Contact/Folder06 - Je suis un vendeur professionnel/01 - Contact (équipe commerciale) - Spanish |
| Commentaire de Thomas Bentley [ 20/janv./11 11:50 ] |
| Egalement sur UK |
| Commentaire de Pablo Anton [ 20/janv./11 11:50 ] |
|
Publié sur REF .- ES
/online_help/Help Forms/Folder Vendeur PRO/Contact équipe commerciale (PROD ADMIN CO/Messagerie) - Spanish |
| Commentaire de Habib-Sylvain Gourguet [ 20/janv./11 11:53 ] |
| /online_help/Help Footers/(f) Contact (équipe commerciale) |
| Commentaire de Thomas Bentley [ 20/janv./11 11:57 ] |
| Suite message Pablo (11h50): egalement UK |
| Commentaire de Pablo Anton [ 20/janv./11 12:10 ] |
|
Corrigé et publié sur REF - ES
/online_help/Help Articles/Folder02 - FAQ/Contact/Folder06 - Je suis un vendeur professionnel/01 - Contact (équipe commerciale) - Spanish |
| Commentaire de Pablo Anton [ 20/janv./11 12:18 ] |
|
Publié sur REF - ES
/online_help/Help Footers/(f) Contact (équipe commerciale) |
| Commentaire de Thomas Bentley [ 20/janv./11 12:19 ] |
| Egalement sur UK |
| Commentaire de Habib-Sylvain Gourguet [ 20/janv./11 12:26 ] |
| Contents et structures publiés sur REF et BRANCH pour FR/ES/UK. |
| Commentaire de Espérance Galouo-Lece [ 20/janv./11 14:50 ] |
|
- Trop de différence entre REF, BRANCH et INTEG (cf. screenshot-1)
- Les dump pour l'INTEG sont directement pris de la BRANCH et non de REF. |
| Commentaire de Espérance Galouo-Lece [ 20/janv./11 14:52 ] |
| - Et pas de formulaire en INTEG (cf. screenshot-2) |
| Commentaire de Habib-Sylvain Gourguet [ 20/janv./11 15:27 ] |
|
Pour les écarts entre REF, BRANCH et INTEG, rien d'anormal
dans le sens où nous travaillions récemment sur la réorganisation de la
FAQ pour la v85.
Pour le formulaire absent en INTEG, je suis en train de regarder. Tout est publié normalement sur CMS-BRANCH et CMS-REF, et a été testé avant publication sur FO-REF : http://www.ref-fr.pm.dev/help/c_contact_pro/popup/true |
| Commentaire de Habib-Sylvain Gourguet [ 20/janv./11 15:35 ] |
|
Publié sur BRANCH pour FR/ES/UK :
/ONLINE_HELP/CONTACT/VOUS_ETES_UN_VENDEUR_PROFESSIONNEL/CONTACT_EQUIPE_COMMERCIALE Pointait sur un "OldContent" pour le formulaire. Sorry. :-( |
[APP-32136] Historisation des FdP à l'autorisation Création: 06/déc./10 18:51 Mise à jour: 31/janv./11 16:10 Résolue: 24/janv./11 14:17 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 86.0.0 (TX-R) |
| Version(s) corrigée(s): | 86.0.0 (TX-R) |
| Type: | Nouvelle fonctionnalité | Priorité: | Majeur |
| Rapporteur: | Arnaud Forgues | Attribution: | Yann Danot |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Projets PM: | *** RESERVE *** |
| Description |
|
Afin de permettre le rapprochement de VA à l'autorisation
pour l'équipe BI, on souhaite stocker le montant des FdP à
l'autorisation du panier.
Ces infos seront visible en BO sur la fiche article et autres (détails à venir) |
| Commentaires |
| Commentaire de Vincent Jouffe [ 31/janv./11 16:10 ] |
| ok |
[IMP-6913] [UK] Extraction et paramétrage compte vendeur GamePimp Création: 03/sept./10 11:19 Mise à jour: 02/nov./10 14:01 Résolue: 02/nov./10 14:01 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Demande commerciale |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Jeremy Pallot | Attribution: | Jérome Marianne |
| Résolution: | Aucune correction envisagée | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
GBR - Royaume Uni
|
| Login: | gamepimp |
| Séparateur: | Point-virgule (;) |
| Type de traitement: |
Mise à jour/création annonces (écrasement)
|
| Description |
|
Bonjour, Pouvez-vous faire un extrait de stock (BI ou web service) et puis paramétrer le compte du vendeur Gamepimp. Pas de FTP, mise à jour via front office. Pour mémoire c'est le compte avec 7000 annonces à valider. Merci, |
| Commentaires |
| Commentaire de Jérome Marianne [ 09/sept./10 14:12 ] |
| Tests en cours pour tenter de valider par format import. |
| Commentaire de Jérome Marianne [ 13/sept./10 10:58 ] |
|
Le fichier test n'a pas fonctionné.
Après avoir vu Patrick de l'équipe Exploitation il ne voit pas d'attribut qui pourrait agir sur le statut de la fiche produit. Lui même de son coté ne peut le faire automatiquement car cela entraine des risques collatéraux sur la base. J'ai envoyé un mail à Manuel Sadok pour voir s'ils connaitraient un autre moyen de valider les fiches automatiquement. J'attends sa réponse. |
| Commentaire de Jérome Marianne [ 14/sept./10 16:19 ] |
|
Pour manuel il faut passer par l'import il ne voit pas de possibilité.
En attente d'infos de la part de Gael suite au mail de jerome Vivies. |
| Commentaire de Jérôme Viviès [ 14/sept./10 17:03 ] |
|
Il y a eu des échanges par mail au sujet de cette demande -
je recolle la conversation ici pour que tout le monde poursuive dans le
JIRA :
De : Eric Vannier [mailto:eric.vannier@priceminister.com] Envoyé : mardi 14 septembre 2010 11:47 À : Daniel Pintamalli Cc : Gael Seguillon; Jeremy Pallot; JUSTIN ZIEGLER; exploitation; Christophe Garcia; Jerome Vivies; Manuel Sadok; Patrick Pereira; Sebastien Raguet; Pierre Bret Objet : Re: [SUPERVISION] - Etat de sante de la plateforme 2010-09-14 Pour info, l'"out of memory" est du à un fichier plat issu des requêtes utilisateurs trop gros. Un jira va être crée pour limiter la taille de ce fichier pour éliminer ce risque de plantage. Le 14 septembre 2010 11:41, Daniel Pintamalli <daniel.pintamalli@priceminister.com> a écrit : Gaël, peux tu vérifier le PRO GamePIMP (UK)? On devrait lui assigner un format pour empêcher qu’il continue à remplir sa boutique par FO. Il en a déjà soumis 7000 et on se pose la question comment a-t-il fait pour en créer autant… Daniel De : Patrick Pereira [mailto:patrick.pereira@priceminister.com] Envoyé : mardi 14 septembre 2010 11:33 À : Daniel Pintamalli; Eric Vannier; Sebastien Raguet; Pierre Bret Cc : JUSTIN ZIEGLER; exploitation; Christophe Garcia; Jerome Vivies; Manuel Sadok Objet : RE: [SUPERVISION] - Etat de sante de la plateforme 2010-09-14 Le traitement de cette nuit montre que le partenaire continue à insérer à la main (ou par script) des produits qui devront être valider ? Non ? Ne faudrait-il pas le contacter pour qu’il arrête ? De : Daniel Pintamalli [mailto:daniel.pintamalli@priceminister.com] Envoyé : mardi 14 septembre 2010 11:28 À : Patrick Pereira; Eric Vannier; Sebastien Raguet; Pierre Bret Cc : JUSTIN ZIEGLER; exploitation; Christophe Garcia; Jerome Vivies; Manuel Sadok Objet : RE: [SUPERVISION] - Etat de sante de la plateforme 2010-09-14 Concernant GamePIMP : Voir L’équipe validation nous a demandé de valider en masse 7000 annonces soumis à la main pour un PRO anglais mais on s’est posé la question si ce n’est pas un script qui a fait cela car 7000 annonces à la main c’est impossible… Daniel De : Patrick Pereira [mailto:patrick.pereira@priceminister.com] Envoyé : mardi 14 septembre 2010 10:57 À : Eric Vannier; Sebastien Raguet; Daniel Pintamalli; Pierre Bret Cc : JUSTIN ZIEGLER; exploitation; Christophe Garcia Objet : RE: [SUPERVISION] - Etat de sante de la plateforme 2010-09-14 Bonjour. Affectation en rouge. J’ajoute pour aujourd’hui Daniel pour la pb d’import sur GamePIMP. J’ajoute Pierre Bret pour AdsBot Google. Merci. Patrick. |
| Commentaire de Jérôme Viviès [ 14/sept./10 17:17 ] |
|
Salut,
Je résume pour faire un état des lieux : - le partenaire a créé des milliers de produits via front office (!) - on se demande comment - et visiblement il continue... - c'est un souci : les partenaires ne sont pas censés créer massivement des FP en FO avec des robots... Exploit' = pas glop ! - ces produits tombaient chez l'équipe Validation - qui a passé le partenaire en validation automatique - pour les produits créés non validés, pas de possibilité pour la Validation de valider en masse (l'outil ne fonctionne pas) - la demande de ce JIRA n'est pas valide : on ne peut pas extraire un stock et valider les produits par import Solution proposée : - contacter le partenaire, lui dire d'arrêter son mécanisme de soumission FO ; - supprimer tous ses produits non validés ; - lui demander un fichier d'import et faire un import standard. Ok pour tout le monde ? Merci de vos réponses rapides :) |
| Commentaire de Julien Buhagiar [ 16/sept./10 10:58 ] |
|
J'ai appelé le pro (en vain).
Mail envoyé pour le prévenir que sa façon de lister les produits n'était pas la bonne. Je lui communique le fichier d'import Jeux Vidéos (UK). Si je n'ai pas de retour d'ici demain après-midi, je referai une tentative pour l'avoir au tél. A dispo si besoin Julien B. Service Co. |
| Commentaire de Jérome Marianne [ 27/sept./10 18:24 ] |
| Des nouvelles de ce pro? |
| Commentaire de Gaël Seguillon [ 14/oct./10 13:13 ] |
|
On laisse tomber on ferme le Jira
merci Gaël |
| Commentaire de Aurélien Vergalli [ 14/oct./10 13:17 ] |
|
Est-il possible de supprimer ses 4000 FP soumises qui nous "encombrent" dans le BO ?
Merci |
| Commentaire de Jérome Marianne [ 14/oct./10 15:51 ] |
| Il faut la validation de Gaël ou de Jérémy pour la suppression des 4000 fiches produits. |
[BIN-124] étude sur les canaux d'acquisition des Op jeux concours Création: 03/août/06 10:39 Mise à jour: 14/sept./07 17:17 Résolue: 17/août/06 11:06 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Thomas Beylot | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | 1 jour | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | 1 jour | ||
| Description |
|
Hello, suite à ma discussion avec Agathe (je ne comprends toujours pas à qui vont les jira en premier lieu même si je me doute que tu es en train de le lire, Agathe, alors je te parle sans te parler, bref) voilà ma toute dernière requête BO: Contexte: Lorsque nous montons des Op de jeux concours, nous recrutons un certains nombre de nouveaux prospects. Certains font une action sur le site directement après leur participation au jeu en provenant des points de redirects installés sur le jeu lui même, quand d'autres transforment à posteriori. En cours d'OP, tous les prospects (exceptés ceux qui se dont inscrits dans la foulée du jeu, donc) sont intégrés à la base avec un first tracking défini au préalable. Ainsi, ces prospects rentrent dans le programme d'automatisation, mais aussi dans le programme de newsletters avec comme objectif de les faire acheter/vendre. Au cours du temps, on remarque que ces prospects continuent de transformer et le taux de transfo sur cette base s'améliore donc. Demande précise: L'idée est donc de savoir par quel biais ces prospects transforment. Ainsi, j'aimerais croiser les first tracking du groupe jeu-concours (dans lequel on met toutes les OP, du jeu Tante Odette au jeu auto en passant par astérix) avec tous les last tracking pour savoir par quel moyen un prospect transforme. On pourra ainsi savoir si les messages qu'on lui envoie sont efficaces, ou si au final, on le "rachète" via un comparateur ou autre. Petite précision, la première OP qui m'intéresse a commencé en octobre 2005, et donc la période s'étale jusqu'à aujourd'hui, et à fortiori ce rapport devrait me servir dans le temps (tous les mois, au même titre que purchase by month). Je reste à votre dispo pour éclaircir ma demande au cas où. merci ! |
| Commentaires |
| Commentaire de Thomas Beylot [ 03/août/06 16:10 ] |
|
bon alors en fait voilà ce qu'il me faut : sur le tracking group jeux-concours par tracking name il me faudrait savoir par quel biais les comptes enregistrés avec le first tracking considéré ont acheté et/ou vendu sur le site (ex: newsletter, google, yahoo... etc.) Ainsi, je pourrais savoir que sur tel tracking name, 60% des comptes enregistrés ont transformé via les mots clés, 10% via les news etc. Je souhaiterais pouvoir faire cela sur chaque tracking name, mais aussi sur le tracking group en pondérant les différent résultats de chaque tracking name par le nombre de comptes de chacun. Il me faudrait aussi à l'instant où le rapport est actualisé, le pourcentage des comptes du first tracking (sur le tracking name, et sur le tracking group) qui ont acheté, qui ont vendu, et qui ont acheté et vendu. voilà, si ce n'est pas clair, tu sais où me trouver :) |
| Commentaire de Agathe Remy [ 03/août/06 17:29 ] |
|
dimensions : purchase authorisation month, purchase tracking group name, purchase tracking name indicateurs : New buyer count conditions : Authorized purchase Select authorization month period Select user first tracking |
| Commentaire de Samir Beghdadi [ 09/août/06 13:25 ] |
|
Slt, Le rapport sur de l'étude sur les canaux d'acquisition des Op jeux concours demandé par Thomas est enfin pret sous le nom "Purchase/V1.1/Users by first tracking" |
| Commentaire de Agathe Remy [ 17/août/06 11:06 ] |
|
Le rapport a été livré en Production sous : Marketing/First tracking/User transformation by first tracking Dis-nous ce que tu en penses?! Merci:-) Agathe |
[APP-18282] [CBV]: Probleme de WAE_TYPE_CODE sur les évenements warranty Création: 18/oct./07 10:23 Mise à jour: 19/oct./07 15:00 Résolue: 18/oct./07 17:15 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 17.0.0 |
| Version(s) corrigée(s): | 17.1.0 |
| Type: | Bogue | Priorité: | Bloquant |
| Rapporteur: | Romain Czornomaz | Attribution: | Renaud Dierickx |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
screenshot-1.jpg
|
||||||||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Site: | Prod | ||||||||
| Projets PM archivés: | Contrat "Bris et Vol" (Lot 2) | ||||||||
| Description |
|
Bonjour, En vérifiant dans le BI les dénormalisations de la REFUND_DATE dans les Warranty nous avons découvert un bug concernant une garantie passé en état REFUNDED. La garantie porte le numéro 2766. En vérifiant les évéenements sur la garantie, l'évenement de REFUND (WAR_STATUS_CODE=50), on observe que le code de l'evenement (WAE_TYPE_CODE) est 110 (Misc) alors qu'il devrait etre 90. Ce probleme est bloquant coté BI car cela nous empeche de créer correctement les dénormalisations de la date de remboursement sur les garanties. Merci d'avance pour la correction, Romain |
| Commentaires |
| Commentaire de Renaud Dierickx [ 18/oct./07 11:31 ] |
|
Cette garantie est issus d'un bug ( Elle est associée à un article mais elle n'a jamais été payée... Le BO l'a mise en REFUND car ils ne peuvent mettre un autre état. Je vais donc corriger celle-ci via un script qui la mettre en DELETED (en mettant à jour la change_date). Je mettrai un évènement de type 'Destruction' (WaeTypeCode = 30 : "Destruction de la garantie") et un description explicite (Change REFUND waranty status to DELETED to fix bug Ensuite, pour la modification d'état depuis le BO, je vais modifier la façon de faire : - si passage à WarStatusCode.CONFIRMED -> WaeTypeCode.CONFIRMATION (70 : "Confirmation de la garantie") - si passage à WarStatusCode.REFUNDED -> WaeTypeCode.ITEM_CLAIM (90 : "Annulation de la garantie par rétractation") - si passage à WarStatusCode.RETRACTED -> WaeTypeCode.RETRACTATION (80 : "Annulation de la garantie par réclamation article") Steven et Romain, vous êtes ok ? |
| Commentaire de Romain Czornomaz [ 18/oct./07 12:28 ] |
|
Renaud, Pour moi c'est ok. Romain |
| Commentaire de Renaud Dierickx [ 18/oct./07 12:40 ] |
|
J'ai écris le script et j'attends le retour de patrick pour
le passer en production. (V:\Database\V17_1_0\dev\V17_1_0_ Pour voir ce que ça donne, voir screenshot (après passage du script en dev). |
| Commentaire de Renaud Dierickx [ 18/oct./07 17:15 ] |
|
C'est bon, le script est passé ! Steven, merci d'alerter Claire que la garantie est passée en état "supprimée". |
| Commentaire de Sébastien Aubert [ 19/oct./07 14:48 ] |
| ok garantie supprimé en prod |
| Commentaire de Steven Harel [ 19/oct./07 15:00 ] |
|
super, merci la garantie a disparu des pages item et purchase on a retenté la capture du panier |
[APP-31524] Réclamation "en cours" mais transaction "rejetée" Création: 26/oct./10 18:28 Mise à jour: 17/janv./11 16:23 |
|
| Etat: | Ouvert |
| Projet: | Application PriceMinister |
| Composants: | Back-Office |
| Affecte la/les version(s): | 79.0.3.2 |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Habib-Sylvain Gourguet | Attribution: | Dispatcher (Pôle TX) |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM: | *** CHASSE *** |
| Description |
|
Voir la fiche-article suivante :
http://bo.priceminister.com/purchase_back?action=itemview&itemid=143283322 Après vérification via rapport BI, une seule autre transaction était concernée, mais le bloc "claim" pouvait encore être modifié. Ici, impossible, le bloc est figé. Rien de bloquant, mais l'état de claim peut fausser quelques chiffres (rapports BI, Dashboard...). |
| Commentaires |
| Commentaire de Emeric Teil [ 17/déc./10 10:48 ] |
|
Complément d'info par Laura :
" En traitant les 7 jours, j’ai utilisé la macro « diff – pas de réponse – retour V part ». Le reste ne sont que des mails envoyé manuellement : - Mail blanc car c’est un pro, mais finalement vu avec Jeff pas de traitement pro vu le profil V. - Suite au retour de l’Acheteur, une de nos nouvelles opératrices m’a transmis la transaction. Vu le montant j’ai voulu « forcer » le retour de l’article avant de rembourser, cf. les 2 mails du 22/10. A noter que la transaction n’est plus retombée dans les 7 jours, suite à l’utilisation de la macro. " |
[META-TACHE] Modification des tracking sites-under + tracking e-mails questions
(APP-26706)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 57.0.0 (CTN-N) |
| Version(s) corrigée(s): | 57.0.0 (CTN-N) |
| Type: | Sub-new feature | Priorité: | Majeur |
| Rapporteur: | Ghislain Gridel | Attribution: | Dispatcher (Pôle CTN) |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Classif FONC: | webanalytics |
| Projets PM archivés: | Tracking affiliation |
| Description |
|
Bonjour, voilà le brief sur le tracking question. 1/ Contexte : Aujourd'hui dans le pilotage des canaux marketing, nous distinguons le volume d'affaire généré par des trackings de celui généré sans tracking. Ainsi, l'ensemble tracking/No tracking = 100% du volume d'affaire PriceMinister. Le volume d'affaire sans tracking correspond à du trafic spontané ou du référencement naturel. Le volume d'affaire avec tracking inclue tous les canaux payants (acquisition), ainsi que la fidélisation (CRM et newsletters), les services (parrainage, widgets, souhaits, ami, question). L'ensemble de ces trackings sont dédupliqués entre eux. Le dernier tracking avant l'authentification se voit attribuer le panier. 2/ Réflexion : - Nous avons pris conscience que certains de ces canaux n'avaient pas de raison de rentrer dans ce système de tracking. ils prennent la place de canaux payants. C'est le cas du tracking « Question au vendeur » disposé sur tous les emails applicatifs signalant à l'acheteur que le vendeur a répondu à la question. Ce tracking vient s'imposer comme last tracking et le panier lui est attribué à la place d'un éventuel partenaire : « Kelkoo » ou « Google livres » par exemple. Le risque est de ne plus enchérir sur un mot clef réputé non rentable car la transformation n'est pas associée à ce mot clef. Dans les faits, ce mot clef peut être rentable mais le système actuel nous cache sa véritable rentabilité. Voilà un exemple d'email : ------------------------------------ Bonjour guibrel, fender13 a répondu au message que vous lui avez laissé à propos de l'article suivant : Porte Bébé Dorsal Pour consulter sa réponse, merci de cliquer sur le lien suivant : http://www.priceminister.com/question?action=view&aid=225507967&t=40 Merci de votre confiance et à très bientôt sur PriceMinister. http://www.priceminister.com l'Achat-Vente Garanti ---------------------------------- - Nous nous apercevons en conséquence que sur les canaux que nous payons au CPC, nous ne retrouvons pas la rentabilité attendue malgré le bon travail effectué. Par exemple sur les liens sponsorisés, d'autres indicateurs nous démontrent que la stratégie est la bonne : Quality score élevé des campagnes, redirect précis sur les fiches produits et taux de clic élevé. Ce qui nous a amnée à entamer cette réflexion. Le système de last tracking est-il défavorable à ces canaux car ils sont moins proche du last clic que d'autres ? mais pour autant restent des contributeurs importants à la transformation ? « Question au vendeur » doit-il continuer à usurper les paniers de nos partenaires ? est-ce juste ? Ne devrait-on pas mieux considérer ces canaux ? - D'autres réflexions sont en cours sur l'intégration du CBV, et du revenus monétisation dans le calcul du résultat 3/ Problématique : Toute modification du système implique une rupture avec l'historique et avec l'équilibre général des différents canaux. Nous devons donc être prudents. Le tracking question représente environ 14% du volume d'affaire total du site. En enlevant le tracking question ces 14% vont se diffuser sur l'ensemble des autres canaux, de telle sorte que chaque canal devrait voir son volume d'affaire augmenter de 14% (toutes choses égales par ailleurs). 4/ Besoin : Dans un premier temps, il faudrait pouvoir double tracker tous les emails applicatifs question au vendeur : le tracking comme aujourd'hui + le tracking xiti parallèle (appelé « autopromo »). Nous pourrons ainsi voir si xiti donne des chiffres proches de BI. Dans un deuxième temps, après analyse et après un « go » officiel, il faudra enlever le tracking t=40 définitivement. Est-ce que cela est possible ? si oui quelles sont les différentes étapes techniques ? A votre dispo pour toute question Ghislain |
| Commentaires |
| Commentaire de Thomas Beylot [ 30/juil./09 09:23 ] |
|
à noter dans ce brief qu'il faut souligner le fait que le
tracking t=40 permet aujourd'hui de suivre sur l'activité quesitons: - le VA et comm - mais aussi un "taux de clic" (qui laisse présager du taux d'ouverture), vu que nous ne pouvons pas suivre celui ci directement. > indicateurs qui nous ont permis récemment d'identifier un pb de délivrabilité des emails applicatifs ! il est donc primordial de retrouver ces indicateurs là sous quelque forme que ce soit (à priori techno tracking "autopromo") et de se rendre compte de l'écart entre ancienne strat et nouvelle strat. A noter que ce faisant, nous perdons toute possibilité de faire de futures analyses BI sous le tracking questions. thomas. |
| Commentaire de Charles Decaux [ 30/juil./09 11:21 ] |
|
Une fois qu'on sera confiant sur la France, c'est-à-dire
après le premier temps, il faudra mettre en oeuvre le deuxième temps sur
ES et UK Merci |
| Commentaire de Swan Desportes [ 30/juil./09 14:33 ] |
|
Hello. Cette demande sera prise en compte dans le cadre du
projet "plan de marquage" prévu pour la prochaine version. Très concrètement, chaque mail ayant un code de tracking compris entre 10 et 50 se verra doté du système de tracking autopromo, en doublon du tracking classique. Le système d'autopromos ne donne pas le taux d'ouverture. Nous le ferons avec le xtor qui propose un système pour suivre le taux d'ouverture. A noter : - sera fait pour tous les pays, tous les cobs - absolument aucun impact sur le tracking PM actuel : pas d'activation du t=50, pas de risque de perte du t=40 |
| Commentaire de Thomas Beylot [ 30/juil./09 14:58 ] |
|
euh attention, car si sur le tracking 40 il y a consensus je
ne crois pas que cela soit le cas sur les autres (parrainage, souhait
etc) en effet nous avons besoin d'analyses BI (first tracking notamment) sur ces sujets, et ça en le migrant dans autopromo nous ne l'aurions plus. J'en ai déjà fait part à Odile qui était ok. thomas |
| Commentaire de Fabrice Feugas [ 27/oct./09 19:14 ] |
| Corrigé avec le projet "tracking affiliation" --> Il n'y aura plus de t=40 dans les e-mails questions |
[EXP-931] Normaliser la documentation des serveurs. Le faire obligatoirement aprés une installation de serveur. Création: 18/janv./06 16:39 Mise à jour: 25/juin/07 18:55 Résolue: 30/janv./06 11:54 |
|
| Etat: | Fermé |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Jérémie Bennejean | Attribution: | Sébastien Tournay |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Ex pour Jacquard : ¿ Configuration matérielle Marque: DELL Modele: Poweredge 2850 Processeur: Intel Bi Xeon 3 Ghz 8 Go de DDR2 6 disques durs 146 Go scsi Garantie bronze 3ans j+1 1 carte raid bi-canal PERC 4e/Di (Intégré) 2 cartes raid bi-canal PERC 4/DC 2 baies powervault 220s 14 disques durs scsi 146 Go en RAID 10 Service TAG de JACQUARD 2SZVT1J Service TAG de la baie 1 BNFYT1J Service TAG de la baie 21 CNFYT1J Notre numéro client DELL : FR2325228 Numéro de téléphone du support : 0825 387 270 Garantie bronze valable jusqu'en : septembre 2008 DELL OPEN MANAGE --> https://jacquard:1311/servlet/OMSAStart?mode=omsa |
| Commentaires |
| Commentaire de Sébastien Tournay [ 30/janv./06 11:54 ] |
| Je ferme cette demande. Il faut suivre cette documentation dans le WIKI en fonction de chaque nouveau serveur. La demande de documentation sera formulée dans la tache JIRA correspondant à l'installation du serveur |
[BIN-315] [Jeu Super Vendeur ES] : Extract membres Espagne Création: 05/avr./07 12:00 Mise à jour: 14/sept./07 18:03 Echéance: 11/avr./07 00:00 Résolue: 11/avr./07 18:22 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Nydia Yallico | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ESP - Espagne
|
| Description |
|
Bonjour, nous lançons le jeu super vendeur en Espagne le 17 avril 2007, aussi nous avons besoin d'un extract des membres du site Espagne sur le ciblage suivant : - abonnés à au moins une news y compris offres partenaires L'idéal serait d'avoir un rapport sous BI pour pouvoir exploiter ces données. date limite de livraison le mercredi 11 avril Merci, Nydia et Charles |
| Commentaires |
| Commentaire de Agathe Remy [ 05/avr./07 18:29 ] |
|
Nydia et Charles, Pouvez-vous me dire quels sont les informations qui vous sont nécessaires : pseudo ??? Merci:-) |
| Commentaire de Agathe Remy [ 10/avr./07 19:16 ] |
|
Nydia, J'ai créé un rapport "Optin emails listing" dans le répertoire Spain/Games dans BusinessObjects. Dis-moi s'il te convient?! Et n'hésite pas si tu as des questions... Agathe |
| Commentaire de Nydia Yallico [ 11/avr./07 18:20 ] |
|
Merci Agathe, le rapport me convient tout à fait ! Nydia |
| Commentaire de Agathe Remy [ 11/avr./07 18:22 ] |
|
Je clôture donc ce JIRA:-) Agathe |
[BIN-297] Revenus par catégorie par mois : données incohérentes Création: 27/févr./07 19:40 Mise à jour: 14/sept./07 18:02 Résolue: 01/mars/07 20:05 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Charles Decaux | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Data bizarres CA.xls
|
| Pays: |
FRA - France
|
| Description |
|
Dans le rapport Mes Dossiers --> Favoris --> Charles --> CA par catégorie Les données de décembre 2006 sont très inférieures à celles de janvier 2007 ce qui me semble étonnant. En pièce jointe les données que j'ai obtenues sous BI Est-ce qu'on explique une telle différence ? Merci de ton retour Charles |
[BIN-320] [Cobranding/Vehicle] : Evolution des rapports de cobranding Auto suite à la mise en place de la nouvelle offre Création: 07/mars/07 17:35 Mise à jour: 02/janv./08 11:20 Résolue: 02/janv./08 11:20 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Partners |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Ghislain Gridel | Attribution: | Romain Czornomaz |
| Résolution: | Invalid | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Agathe, Les rapports (rappots de l'Intranet) des co-brandings auto sont cassés depuis le 1er mars. En effet il n'y a plus de paiement donc les dépôts d'annonces ne sont plus comptabilisés. Cela est très problématique. Comment faire ? Peut-on faire un rapport BI ? La deadline est le 31 mars pour trouver une solution. Merci de ton retour. Ghislain |
| Commentaires |
| Commentaire de Ghislain Gridel [ 12/mars/07 10:51 ] |
|
Agathe, as-tu pu mettre cette demande sur ton planning ? Je suis incapable de donner des chiffres à mes partners... malheureusement. Merci de me tenir au courant. Ghislain |
| Commentaire de Agathe Remy [ 12/mars/07 12:35 ] |
|
Nous en raparlerons demain à la réunion Post Mortem "Nouvelle offre auto"... Agathe |
| Commentaire de Agathe Remy [ 13/avr./07 16:48 ] |
|
Romain, Peux-tu faire valider les spécifications des rapports? Merci:-) Agathe |
| Commentaire de Ghislain Gridel [ 26/avr./07 12:27 ] |
|
Agathe, il s'agit de créer un nouveau rapport listant les nouveaux membres qui font un premier dépôt d'annonce auto. Pour redoute, libé et Midi Libre. Ce rapport est à adresser à Thomas Merlin. Ghislain |
| Commentaire de Ghislain Gridel [ 26/avr./07 12:29 ] |
|
IL faudra aussi l'nvoyer au partenaire. Merci. Ghislain |
| Commentaire de Romain Czornomaz [ 14/juin/07 11:56 ] |
|
Ghislain, Je bloque la demande en attendant que les decisions statégiques soient prises. Bonne journée, Romain |
| Commentaire de Agathe Remy [ 02/janv./08 11:20 ] |
|
La demande a été annulée. Agathe |
Installation serveur outils de développement (PERRIER)
(INF-7)
|
|
| Etat: | Résolu |
| Projet: | Infrastructure |
| Composants: | Réseau |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | Patrice Boulanger | Attribution: | Stéphane Eccli |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Le serveur sera à prendre dans le stock des 1950 non utilisés. Configuration: - 1950, bi-proc/dual core - 8 Go de RAM - 2x146Go - carte FC (attention compatibilité PCI-X / PCIe) Ce serveur doit être raccordé au SAN CX3-20. A racker dans la biae dév (n°7) |
| Commentaires |
| Commentaire de Stéphane Eccli [ 14/avr./08 18:28 ] |
| ok serveurs rackés |
[INF-40] Temps réseau ou accés ruinart lent Création: 25/avr./08 16:46 Mise à jour: 15/juil./08 14:06 Résolue: 15/juil./08 14:06 |
|
| Etat: | Résolu |
| Projet: | Infrastructure |
| Composants: | Réseau |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Nicolas Chauveau | Attribution: | Stéphane Eccli |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
L'équipe dev qui se trouve dans le couloir entre QDC et le BI a des pb de lenteur : - Accès aux répertoires 'group' - CVS - wiki - Jira - eclipse (qui accède à Ruinart pour CVs et à U: pour les fichiers sources distants) hypothèses : - Ruinart très lent - Pb réseau ? Pour plus d'info voir : Manuel Sadok , Edouard Gomez-Vaëz |
| Commentaires |
| Commentaire de Stéphane Eccli [ 15/juil./08 14:06 ] |
| allegement en cours |
[BIN-485] [Media] : Nombre de nouveaux vendeurs "vidéo" Création: 11/sept./08 12:39 Mise à jour: 10/juin/09 19:56 |
|
| Etat: | Ouvert |
| Projet: | Business Intelligence |
| Composants: | CRM |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Cosmétique |
| Rapporteur: | Thomas Beylot | Attribution: | Julien Girardet |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Hello je souhaiterais pouvoir avoir sous BI un rapport présentant le nb de vendeurs par mois ayant fait leur première vidéo. je ne me rends pas compte de la difficulté mais comme ça j'ai l'impression qu'il s'agit d'un rapport simple non ? si oui je peux peut être assister à sa création ? merci beaucoup |
| Commentaires |
| Commentaire de Agathe Remy [ 15/oct./08 17:02 ] |
|
Bonjour Thomas, Après étude, pour te fournir ce nouvel indicateur (nb de vendeurs ayant déposés leur 1ère vidéo), il nous faut créer une dénormalisation (date de 1er dépôt d'une vidéo) dans le Datawarehouse et donc faire évoluer l'alimentation. Ceci est donc plus coûteux que de simplement créer un indicateur dans l'univers. Cette information est-elle donc réellement nécessaire pour justifier ce coût (et si oui pourquoi) ? Merci. Agathe |
| Commentaire de Thomas Beylot [ 21/nov./08 09:03 ] |
|
Hello désolé j'ai mis du temps à répondre. pour donc apporter une réponse concrète ben je te dirais que oui c'est important. Et pour le justifier, ben je sais pas trop quoi te dire mis à part que ce serait comme de ne pas regarder le nb de nouveaux acheteurs ou vendeurs par mois... tu en veux plus ? thomas |
| Commentaire de Agathe Remy [ 21/nov./08 14:11 ] |
|
Aide-toi et le ciel t'aidera... Ce que je te demande, c'est une justification business concrète, du type : "cela me permettra d'évaluer, de prioriser ou de suivre telle ou telle action prévue à telle date dont l'apport en VA ou CA estimé est de tel montant" Agathe |
| Commentaire de Thomas Beylot [ 21/nov./08 14:54 ] |
|
ok alors "ça me permettra de suivre toutes les actions qu'on pourrait mettre en place pour recruter de nouveaux vendeurs vidéo et donc d'améliorer la communication à faire si les chiffres constatés ne sont pas bons" et "ça me permettrait de mieux diagnostiquer une éventuelle chute des dépôt d'annonces vidéo, en sachant par exemple si c'est à cause d'un manque d'adhésion au service (joue sur fid) ou d'un manque de visibilité (joue sur recrutement de nouveaux vendeurs vidéo)" par exemple merci |
[BIN-472] [Marketing] : Evolution du rapport "1000Mercis - Buyer value" Création: 05/août/08 10:34 Mise à jour: 04/sept./08 17:41 Résolue: 07/août/08 09:50 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | CRM |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Thomas Beylot | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Hello il faudrait faire évoluer la requête de ce rapport car nous avons depuis sa création mis en place de nouveaux groupes de tracking. Or je ne peux modifier la requête depuis mon compte sous BI. Il faudrait que les champs PL-Mode et PL-culturelle soient compris dans le filtre de référence. merci thomas |
| Commentaires |
| Commentaire de Agathe Remy [ 05/août/08 11:54 ] |
|
Le rapport est dans le répertoire Dossiers publics/Subscription Agathe |
| Commentaire de Cyril Tanneau [ 07/août/08 09:50 ] |
|
C'est bon, j'ai ajouté les deux invites demandées dans la
requête, tu pourras les sélectionner pour les prochains rapports. Peux-tu valider et clôturer le Jira? Merci, Cyril |
| Commentaire de Agathe Remy [ 04/sept./08 14:49 ] |
|
Bonjour Thomas, Peux-tu valider ce JIRA afin que nous puissions le clôturer? Merci. Agathe |
| Commentaire de Thomas Beylot [ 04/sept./08 17:39 ] |
|
super merci Cyril. thomas |
[INF-513] boite générale google mail pour le back office Création: 10/août/10 12:23 Mise à jour: 13/août/10 14:16 Résolue: 13/août/10 14:16 |
|
| Etat: | Résolu |
| Projet: | Infrastructure |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Steven Harel | Attribution: | Stéphane Eccli |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
nous avons de tâches qui doivent être gérées par toute l'équipe ces tâches impliquent l'envoi de rapports/fichiers/fax du BI, de partenaires ou de membres on ne peut pas utiliser les alias réservés à des groupes restreints il nous faut donc une boite google mail générale pour le back office qui recevra tous ces docs et les triera par objet merci |
| Commentaires |
| Commentaire de Steven Harel [ 12/août/10 11:49 ] |
|
nom de la boite : service.clients@priceminister.com merci |
| Commentaire de Stéphane Eccli [ 13/août/10 14:16 ] |
| done |
[EXP-662] Création d'un enregistrement LATONE pour notre DNS interne Création: 22/déc./05 10:56 Mise à jour: 25/juin/07 18:55 Echéance: 22/déc./05 00:00 Résolue: 22/déc./05 15:25 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Evolution |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Sébastien Tournay | Attribution: | Pap Ndiaye |
| Résolution: | Corrigé | ||
| Estimation restante: | 0 minutes | ||
| Temps consacré: | 20 minutes | ||
| Estimation originale: | 20 minutes | ||
| Description |
|
Il faudrait créer dans notre dns interne un enregistrement
pour latone.jm.lan (alias latone). Adresse IP à venir. Il s'agit de la
bdd BI de PROD à laquelle nous allons accéder via l'ARKOON pour
administrer différentes instances Oracles. http://latone:5500/em/ DW http://latone:5501/em/ OWREP http://latone:5502/em/ BOREP |
| Commentaires |
| Commentaire de Sébastien Tournay [ 22/déc./05 13:10 ] |
| l'@IP est 10.150.28.88 sur le réseau privé de PROD |
[BIN-115] ajout de messages automatiques dans les bilans Vendeurs Création: 06/juil./06 12:02 Mise à jour: 14/sept./07 17:04 Résolue: 10/juil./06 14:11 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Nouvelle fonctionnalité | Priorité: | Majeur |
| Rapporteur: | Elodie Pasquale | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | 2 heures | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | 2 heures | ||
| Description |
|
Bonjour, 2 nouveaux messages automatiques partent depuis juin 06 et sont à ajouter dans les bilans Vendeurs sous BI. Il s'agit de : M22-1ereMiseEnVente-j24h code tracking : 1396045 M22bis-1ereMiseEnVente-j30 code tracking : 1402140 Merci Elodie elodie.pasquale@priceminister.com Tel : +33 (0)1 42 78 87 15 |
| Commentaires |
| Commentaire de Samir Beghdadi [ 10/juil./06 14:11 ] |
|
Slt, Je te confirme l'ajout des deux messages dans les bilans Vendeurs. A toi de tester!!!!! Merci. |
[BIN-685] [So Colissimo] Ajouter deux variables dans l'univers USER ACCOUNT pour édition d'un rapport Création: 05/août/10 15:41 Mise à jour: 15/oct./10 10:03 Résolue: 31/août/10 18:45 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | BackOffice |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Nouvelle fonctionnalité | Priorité: | Majeur |
| Rapporteur: | Thomas Landru | Attribution: | Fabrice Lima-Lopes |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Dans le cadre du projet So Colissimo on souhaiterait éditer
un rapport BI au sujet des vendeurs transfrontaliers ayant chochés so
colissimo et chronopost dans leurs préférences vendeurs. Pour cela il faudrait intégrer dans BO les variables suivantes : - user_account.supports_shipping_colissimo - user_account.seller_country_id Merci d'avance ! |
| Commentaires |
| Commentaire de Habib-Sylvain Gourguet [ 06/août/10 16:39 ] |
|
Et "puisqu'on est dessus" (dixit Agathe :-)... Merci d'ajouter une dimension "operation creation month" dans le dossier "User wallet operation" de l'univers USER ACCOUNT. Il n'existe pour le moment qu'une dimension "operation creation date". |
| Commentaire de Fabrice Lima-Lopes [ 31/août/10 18:45 ] |
|
Bonjour, Les nouvelles dimensions ont été ajoutées dans l'univers USER ACCOUNT. Classe Seller: -------------- -Seller allows SoColissimo shipment? (uniquement pour la France) : Indique si le vendeur a accepté le mode d'expédition "SoColissimo". -Seller country Id : Identifiant du pays d'expédition de vendeur. -Seller country name : Nom du pays d'expédition de vendeur. -SoColissimo seller (uniquement pour la France) (Filtre) : Filtre les vendeurs ayant accepté le mode d'expédition "SoColissimo". Classe User wallet operation : ----------------------------- -Operation creation month : Mois de création de l'opération. Peux tu valider la nouvelle fonctionnalité stp? Merci. |
| Commentaire de Agathe Remy [ 13/sept./10 10:04 ] |
|
Bonjour Habib,
Stp, peux-tu valider la demande afin que nous puissions la fermer? Merci, Agathe |
| Commentaire de Agathe Remy [ 14/oct./10 15:40 ] |
|
Bonjour Habib,
Stp, peux-tu valider la demande afin que nous puissions la fermer? Merci, Agathe |
| Commentaire de Habib-Sylvain Gourguet [ 15/oct./10 09:32 ] |
|
Testé, c'est parfait.
Merci ! |
[BIN-671] [BackOffice] : Créer un dossier BO Working GENERAL dans Dossiers Publics Création: 04/mai/10 16:55 Mise à jour: 08/nov./10 11:52 Résolue: 06/mai/10 15:36 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | BackOffice |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Pierre Smith | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Réorganisation des dossiers et
accès à Business Objects pour le Back Office.docx
|
| Pays: |
ALL - Tous
|
| Description |
|
- Créer un fichier BO Working dans Dossiers Publics qui absorbe les actuels France / Spain / UK - Donner le plein accès à modification au login ur_backoffice - Permettre la consultation des dossiers par le login uv_backoffice Descriptif du rendu final disponible dans V:\Paramétrage\BI "Réorganisation des dossiers et accès à Business Objects pour le Back Office.docx" |
| Commentaires |
| Commentaire de Pierre Smith [ 05/mai/10 11:36 ] |
|
Pour précision, on souhaiterait renommer le fichier à la place de "BO Working" On voudrait avoir "Requêtes Back-Office" Est-ce faisable ? Merci |
| Commentaire de Habib-Sylvain Gourguet [ 05/mai/10 11:39 ] |
| Le fichier cité par Pierre en PJ. |
| Commentaire de Agathe Remy [ 05/mai/10 13:04 ] |
|
Bonjour, Comme les dossiers sont classés par ordre alphabétique, nommer ce nouveau dossier "Requêtes Back-Office" le placerait entre "France" et "Spain". Que pensez-vous de proposer un autre nom ? Agathe |
| Commentaire de Agathe Remy [ 05/mai/10 13:07 ] |
|
Si vous voulez qu'il soit placé tout en bas, nous pouvons le nommer "ZZ - Requêtes BackOffice". Qu'en pensez-vous? Agathe |
| Commentaire de Habib-Sylvain Gourguet [ 05/mai/10 13:40 ] |
| Ok pour moi. |
| Commentaire de Pierre Smith [ 05/mai/10 13:52 ] |
| Ne peut-on pas plutôt l'appeler Back-Office Requêtes pour qu'il passe en premier ? |
| Commentaire de Agathe Remy [ 05/mai/10 14:21 ] |
| Ok pour "BackOffice Requêtes" (BusinessObjects n'aime pas trop les "-" dans les noms de dossier...) |
| Commentaire de Agathe Remy [ 06/mai/10 15:36 ] |
|
Bonjour, Le dossier "BackOffice Requêtes" a été créé et livré en Production. Vous avez le droit de faire ce que voulez dedans avec l'utilisateur "ur backoffice" : créer des nouveaux dossiers et rapports, les supprimer, les planifier, etc... L'utilisateur "uv backoffice" a accès en rafraîchissement et planification à tous les documents que vous créerez dans ce dossier, mais sans droit de modification ou suppression. Je vous laisse donc migrer les rapports de BO Working dans la nouvelle arborescence que vous voulez mettre en place. Lorsque vous aurez terminé, je vous prie de me le signaler afin que je supprime les anciens répertoires Bo Working. Bien sûr, nous restons à votre dispo si vous avez des questions. Agathe |
| Commentaire de Agathe Remy [ 13/sept./10 10:10 ] |
|
Bonjour Habib,
Stp, peux-tu valider la demande afin que nous fermions le JIRA? Merci, Agathe |
[BIN-590] [Marketing] : Rapport de suivi du taux d'annulation par type de produit Création: 09/juin/09 09:21 Mise à jour: 18/nov./10 18:07 |
|
| Etat: | Ouvert |
| Projet: | Business Intelligence |
| Composants: | CRM |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Thomas Beylot | Attribution: | Julien Girardet |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Comme vu ensemble en point bi mensuel, je créé donc le jira
pour trace de la demande. Très rapidement il s'agit de mettre sur pied
un rapport nous permettant de suivre le taux d'annulation des vendeurs
particuliers et ce par catégorie de produit. Brief à venir dès lors que nous saurons quand la demande sera planifiée ? thomas. |
[APP-20582] migration templates de mail d'un groupe à l'autre Création: 20/mai/08 17:44 Mise à jour: 28/mai/08 10:09 Résolue: 26/mai/08 14:22 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 22.1.0 |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Steven Harel | Attribution: | Renaud Dierickx |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
migration vers comptabilité - fraudes.xls
templated pmv.xls
templateid pmv.xls
|
| Pays: |
FRA - France
|
| Projets PM archivés: | Maintenance TX-A |
| Description |
|
on aimerait migrer certains templates de mails appartenant à
plusieurs groupes de mails vers un nouveau groupe de mails en pièce jointe le fichier excel avec le titre de chaque mail, son templateid, son groupid de départ et son groupid d'arrivée. il serait pas-mal de pouvoir garder les mêmes templateid histoire de ne pas fausser les rapports du bi |
| Commentaires |
| Commentaire de Renaud Dierickx [ 26/mai/08 13:56 ] |
| Y -a-t-il quelque chose de similaire à faire en Espagne ? |
| Commentaire de Steven Harel [ 26/mai/08 14:29 ] |
|
yes, mais c'est un autre fichier puisque les templateid sont différents pour les mêmes messages rocio, peux-tu créer un nouveau groupe et faire un fichier comme le mien pour l'espagne ? merci |
| Commentaire de Rocio Perez-Garcia [ 27/mai/08 09:27 ] |
| Fichier avec templateid ESP |
| Commentaire de Steven Harel [ 27/mai/08 09:35 ] |
|
rocio, dans ton fichier tu mets un groupid d'arrivée alors qu'il n'est pas créé en prod (?) il faut d'abord créer le groupe, le positionner dans les messages type (en prod) et indiquer ensuite dans ton fchier quel est son id. renaud ne va pas pouvoir migrer des messages vers un groupe qui n'existe pas. |
| Commentaire de Rocio Perez-Garcia [ 27/mai/08 10:00 ] |
| Ah ok, je n'avais pas tout compris. C'est fait. |
| Commentaire de Rocio Perez-Garcia [ 27/mai/08 10:01 ] |
| Merci de prendre en compte pour ESP seulement le fichier templateid |
[IMP-3222] transfert de stock de thierrytame vers plaisirdelir Création: 05/févr./09 10:38 Mise à jour: 30/oct./09 15:43 Résolue: 10/févr./09 14:27 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Jany Marimoutou | Attribution: | Fotigui Tangara |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
20090209_stock_thierrytame.csv
thierrytame_stock.txt
|
| Pays: |
FRA - France
|
| Login: | thierrytame vers plaisirdelir |
| Séparateur: | N/A |
| Type de traitement: |
N/A
|
| Description |
|
message reçu : j'ai actuellement une boutique : thierrytame (part) et nous avons ouvert avec le statut pro la boutique : plaisirdelir nous souhaiterions faire passer tous les produits de la boutique thierrytame à plaisirdelir et de fermer thierrytame est ce possible et si oui, comment faire ? Est-ce possible ? car depuis le BI, je ne peux faire d'export de son inventaire, car le compte thierrytame est en particulier. |
| Commentaires |
| Commentaire de Fotigui Tangara [ 09/févr./09 11:14 ] |
|
Je pense que c'est possible dans la mesure où on peut avoir une extraction de son stock. Je te mets en PJ l'extraction de son stock (pseudo : thierrytame). J'attends que tu confirmes l'import du fichier en PJ. |
| Commentaire de Jany Marimoutou [ 09/févr./09 12:24 ] |
|
Je ne comprends pas. Tu veux que je procède à l'import du fichier sur le compte "plaisirdelir" ? Ce fichier lrosque je l'ouvre, les éléments ne correspondent pas aux en-têtes de colonne, même après conversion dans Excel. |
| Commentaire de Fotigui Tangara [ 09/févr./09 13:31 ] |
|
Non, je voulais simplement que tu jettes un coup d'¿il sur
le fichier du PRO avant que je ne mette en place son format et profil. C'est vrai qu'en ouvrant le fichier, nous pouvons constater que certains commentaires d'annonces se retrouvent dans dans la colonne "ADVERT_ID". Nous allons essayer de traiter le fichier en ignorant les données "textes" se trouvant dans la colonne "ADVERT_ID". Mais comme tu peux le constater, le fichier possède l'ADVERT_ID et l'EAN. Ce que je te propose, c'est mettre les annonces en place sur le compte PRO (plaisirdelir) en se basant sur l'EAN (au cas où il y en a, sinon j'essaierais de créer les annonces avec les ADVERT_ID). Si tu le souhaite, je procède à l'import du fichier... |
| Commentaire de Jany Marimoutou [ 09/févr./09 13:42 ] |
|
fait au plus simple pour toi. mais des produits comme les disques vinyles ne possèdent pas d'EAN. L'ID product reste la seul réf envisageable pour "matcher" les éléments. |
| Commentaire de Fotigui Tangara [ 09/févr./09 14:02 ] |
| OK. |
| Commentaire de Fotigui Tangara [ 09/févr./09 18:02 ] |
| Nouveau fichier (beaucoup plus propre que le précédent). |
| Commentaire de Fotigui Tangara [ 09/févr./09 18:27 ] |
| fichier en cours de traitement |
| Commentaire de Fotigui Tangara [ 10/févr./09 10:55 ] |
|
Le transfert des données s'est effectué à 95% avec 9371
annonces créées sur 9900 lignes trouvées dans le compte part
(thierrytame). Demande traitée. |
[APP-24414] Oubli de création de tracking Google sur l'Espagne Création: 24/févr./09 18:14 Mise à jour: 06/mars/09 10:07 Résolue: 27/févr./09 17:38 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Tracking |
| Affecte la/les version(s): | 41.0.1 |
| Version(s) corrigée(s): | 42.0.0 (CTN-J) |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Charles Decaux | Attribution: | Damien Dorizy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ESP - Espagne
|
| Site: | Prod |
| Projets PM: | *** CHASSE *** |
| Classif FONC: | monetisation |
| Description |
|
Hello, dans les trackings Google qui ont été crées dans le cadre de la migration vers keyade, le tracking 7050 LS-Google-brand a été crée sur la France, mais pas sur l'Espagne. Il faudrait le créer sur l'Espagne donc, rapidement si possible, car du coup nous ne mesurons pas les transformations liées à la marque ni sur keyade ni dans BI. Merci |
| Commentaires |
| Commentaire de Charles Decaux [ 26/févr./09 11:09 ] |
| En fait on a refait un check avec keyade, et les tags liés à des actions d'achat sont mal posés. Tous les autres tags sont bons. |
| Commentaire de Fabrice Feugas [ 26/févr./09 12:50 ] |
| Du coup le groupe existe ou pas? |
| Commentaire de Charles Decaux [ 26/févr./09 13:56 ] |
|
Il y a deux problèmes distincts : - le tracking 7050 n'existe pas - les tags "achat" sont mal configurés. Merci |
| Commentaire de Fabrice Feugas [ 26/févr./09 16:37 ] |
| ok donc on créé le groupe et on traite sur l'autre JIRA pour les tags achat. |
| Commentaire de Damien Dorizy [ 27/févr./09 14:57 ] |
| Ok pour le tracking 7050 : le script est créé. |
| Commentaire de Charles Decaux [ 27/févr./09 16:30 ] |
|
Merci Damien, cependant dans le BO ES je ne vois toujours pas ce code de tracking. Sais-tu quand il sera dispo ? |
| Commentaire de Damien Dorizy [ 27/févr./09 17:01 ] |
| Avec la version CTN-J - 15 mars |
| Commentaire de Aurélie Kwiatkowski [ 06/mars/09 10:07 ] |
| Vu avec Damien, OK |
[IMP-5363] Support auprès du PRO "storymode" Création: 22/févr./10 11:47 Mise à jour: 22/févr./10 11:51 Résolue: 22/févr./10 11:51 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Support entrant |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Fotigui Tangara | Attribution: | Fotigui Tangara |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Login: | storymode |
| Séparateur: | N/A |
| Type de traitement: |
N/A
|
| Description |
|
Bonjour, Société Farzad France pseudo storymode J'ai effectué un envoi de fichier produit par le biais de votre FTP en date du 20/02/2010 hors le changement sur notre compte price minister n'a pas été pris en compte Dans l'attente de vous lire Bien cordialement *************************************************************************************** Bonjour, Pourriez-vous regarder pourquoi le fichier ne passe pas sur le FTP du vendeur : storymode Merci, Isabelle |
| Commentaires |
| Commentaire de Fotigui Tangara [ 22/févr./10 11:49 ] |
|
Bonjour, La demande du PRO a été prise en charge sous la référence Le PRO a déposé un fichier Excel (.xls) et non CSV ou TXT. Nous ne traitons pas les fichiers Excel. Il suffirait qu'il convertît sont fichier au bon format, de préférence au format txt avec comme séparateur la "Tabulation" car le fichier contient 186 points-virgules. Il ne pourra plus utiliser le "point-virgule" comme séparateur de colonne au risque de provoquer des décalages de colonne lors du traitement de son fichier. Cordialement Equipe Import |
[APP-4917] [V2] Mail activation vendeur : version spécifique pour l'auto Création: 10/juin/05 11:38 Mise à jour: 25/juin/07 18:30 Résolue: 15/juin/07 15:44 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 8.0.2b |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Stéphane Archer | Attribution: | Marc Cacheiro |
| Résolution: | Invalid | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
*** Bug de CSW *** Quand un compte devient vendeur par le biais d'une mise en vente AUTO il reçoit le mail standard d'activation d'inventaire (activation vendeur) ... Evolution : dans ce cas précis lui envoyé un mail d'activation vendeur spécifique à l'auto => fait partie du projet (Mon compte light) |
| Commentaires |
| Commentaire de Quentin de Chivré [ 10/juin/05 17:54 ] |
| A spécifier |
| Commentaire de Gaël Caro [ 28/juil./06 12:25 ] |
| A intégrer dans chantier "Mon compte / Auto". |
| Commentaire de Marc Cacheiro [ 15/juin/07 15:44 ] |
| l'activation de l'inventaire n'est pas nécessaire pour les vendeurs auto, et le mail ne leur est plus envoyé. |
[APP-32661] [POST-DEPLOY] : Gestionnaire de commande : Script de migration des item log erronés Création: 31/janv./11 16:38 Mise à jour: 08/févr./11 10:59 Résolue: 01/févr./11 18:01 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 86.0.0 (TX-R) |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Emeric Teil | Attribution: | Yann Danot |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Projets PM: | *** CHASSE *** |
| Description |
|
Suite à la correction du bug qui créait un item log
"réception implicite" alors que la transaction avait été annulée, il
faudrait regarder si on ne peut pas faire un script qui permette de
"récupérer" les item log créés à tort et de les remplacer par le
nouveau...
NB : voir si on les "modifie" ou bien si on les "supprime" + "création" d'un nouveau... attention, aux changes dates pour le BI... |
| Commentaires |
| Commentaire de Julien Girardet [ 31/janv./11 18:34 ] |
|
Actuellement nous ne récupérons pas les item log. Donc comme vous voulez pour les dates.
Julien. |
| Commentaire de Yann Danot [ 01/févr./11 18:01 ] |
| [CAJ2011Q1TX] |
[BIN-613] [Back-Office] : Ajout des indicateurs "Seller claim ratio" et "Seller Cancel Ratio" dans l' univers ITEM Création: 20/juil./09 13:45 Mise à jour: 23/sept./09 12:05 Résolue: 23/sept./09 12:05 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | BackOffice |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Cedric Favero | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Choses qui sont utilisées en permanence sur le BO mais
pénibles à calculer à chaque fois dans BI , ce sont les taux
d'annulation et les taux de réclamations. En effet, ces deux données permettent tres simplement de visualiser un profil vendeur et dans le BI , il faut à chaque fois calculer nombre de choses et faire des requetes croisées pour les avoir. Il serait donc fort utile d'avoir deux indicateurs dans l'univers ITEM (et user?): - un "Seller Claim Ratio" qui retourne le pourcentage d'items avec claims accepted sur le total d'items capturés - un "Seller Cancel Ratio" qui retourne le pourcentage d'items CANCELLED (seller_refused ou seller_time_out uniquement) sur le total d'items autorisés Merci par avance. Cédric. |
| Commentaires |
| Commentaire de Dalila Belkebir [ 23/sept./09 12:05 ] |
|
même demande que le 550. Demande clôturée. Dalila. |
[APP-26025] panier 100% annulé - on capture le cbv quand-même Création: 22/juil./09 15:55 Mise à jour: 17/août/09 11:34 Résolue: 27/juil./09 10:57 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Paiement |
| Affecte la/les version(s): | 49.0.1 (Acc. mode UK + NPF Sports & Loisirs ES + Soldes UK + Suppression HU Informatique ES ) |
| Version(s) corrigée(s): | 50.0.0 (CAT-J) |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Steven Harel | Attribution: | Arnaud Forgues |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
panier emptied + capture not null.xls
panier emptied + capture not null.xls
|
||||||||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Site: | Prod | ||||||||
| Projets PM archivés: | Extensions de garanties (Lot 1) : Articles neufs | ||||||||
| Description |
|
hola ! quelques cas ce matin de personnes qui ont passé une commande en sélectionnant le cbv. les articles du panier sont tous annulés, on devrait alors avoir une capture de 0 euros. sur certains paniers, on capture cependant le montant du cbv !! http://bo.priceminister.com/purchase_back?action=purchaseview&purchaseid=73380742 http://bo.priceminister.com/purchase_back?action=purchaseview&purchaseid=73427954 http://bo.priceminister.com/purchase_back?action=purchaseview&purchaseid=73277653 |
| Commentaires |
| Commentaire de Steven Harel [ 22/juil./09 16:59 ] |
| rapport bi sur les paniers "emptied" avec capture "not null" sur les 30 derniers autorisation days. on retrouve tous les cbv capturés sur des paniers annulés. il y en a 640 pour plus de 2800 euros. |
| Commentaire de Steven Harel [ 22/juil./09 17:16 ] |
| les autorisation dates de ces paniers vont du 10 juillet au 21. le problème est donc certainement toujours en cours. |
| Commentaire de Emeric Teil [ 22/juil./09 17:20 ] |
| Précision : le comportement est le même pour les EG annulées... |
| Commentaire de Emeric Teil [ 22/juil./09 18:00 ] |
| Autre précision : c'est la date de capture qui est intéressante puisqu'elles sont toutes à partir du 16/07, jour du déploiement de la TX-H... :o( |
| Commentaire de Steven Harel [ 22/juil./09 18:05 ] |
| nouveau fichier joint avec dates de capture |
| Commentaire de Arnaud Forgues [ 22/juil./09 18:17 ] |
|
Y'a-t-il un rapport bi sur les paniers "partiels" avec "montant capture <> somme article commité + garantie" ? En effet, je pense que le pb doit être le même pour tous les paniers ou certains des articles ont été annulés par le(s) vendeurs mais pas tous, et du coup on a sans doute capturé le montant des articles restants (+garanties associées) + montant des garanties des articles annulés. Mais cela est beaucoup plus transparent, car ca doit concerné princiapelement le CBV, or on communique sur le montant global CBV dans le panier. Quoi qu'il arrive, la correction du bug prendra en compte les 2 cas ! |
| Commentaire de Clement Balay [ 23/juil./09 14:29 ] |
| ok corrigé sur le tronc |
| Commentaire de Emilien Guichard [ 23/juil./09 14:54 ] |
| OK en DEV |
| Commentaire de Quentin de Chivré [ 27/juil./09 10:14 ] |
|
Quid de l'historique entre V49 et V50 ? Script de detection de ces cas ? Script de correction ? Ou correction manuelle du SAV via PMV ? |
| Commentaire de Steven Harel [ 27/juil./09 10:19 ] |
|
historique traité par le sav. nous avons traité tous les comptes du rapport bi. + le rapport est lancé tous les matins pour traiter les cas de la veille. jusqu'à résolution du bug en prod. |
| Commentaire de Christophe Garcia [ 27/juil./09 17:45 ] |
| Vu par Cédric |
| Commentaire de Arnaud Forgues [ 27/juil./09 18:35 ] |
|
Petit retour concernant le cas des paniers partiellement
capturés : après avoir vu des exemples en PROD qui ne semblaient pas
présenté le bug (exemple : http://bo.priceminister.com/purchase_back?action=purchaseview&purchaseid=73349152), j'ai creusé au niveau technique et je confirme que au final, le bug n'était présent que pour les paniers totalement annulés. Donc la manip en cours par le SAV permettra de bien gérer tous les cas impactés par ce bug. D'autre part, j'ai vu avec la compta (Claudie), le BI (Agathe) et le SAV (Steven), il restera une incohérence au niveau de la base (à cause des paniers capturés alors que dans l'état EMPTIED), mais cela sera bien pris en compte par la compta grâce au fichier excel que tient à jour le SAV sur les remboursements en cours. De plus, une correction des données de capture provoquerait une autre incohérence d'un point de vue compta, car cela rendrait les opérations des remboursements superflues (cela aurait été possible si le remboursement avait été fait via un recredit carte depuis l'extra net SIPS) NB : théoriquement le nombre de panier / remboursement concernés devrait correspondre à la requete suivante qui actuellement donne : select count(purchase_id) from purchase where has_cbv = 1 and (authorization_card_amount + authorization_coupon_amount + authorization_operation_amount) <> (capture_card_amount +capture_operation_amount + capture_coupon_amount) and pch_status_code = 60 and capture_date > TO_DATE('15-07-2009', 'DD-MM-YYYY'); ==> 1106 lignes |
Finalisation installation de BO en PROD
(EXP-772)
|
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Sous-tâche | Priorité: | Mineur |
| Rapporteur: | Sébastien Tournay | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | 4 heures | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | 4 heures | ||
| Liens des demandes: |
|
||||||||
| Description |
|
mettre en place un mécanisme du genre pmjboss pour assurer
les taches start/stop/status/archivelogs pour l'applicatif bo sur TELLUS
|
| Commentaires |
| Commentaire de Ranto Andriambololona [ 28/mars/06 11:15 ] |
| François a commencé à écrire un document d'explite à ce sujet, j'attends de le recevoir ... |
| Commentaire de Ranto Andriambololona [ 29/mars/06 18:45 ] |
|
Dans le document fourni par François Démarrage BO ./ccm.sh -start all ./ccm.sh -enable all ./tomcatstartup.sh Arret BO ./ccm.sh -stop all ./tomcatshutdown.sh |
| Commentaire de Ranto Andriambololona [ 30/mars/06 11:59 ] |
|
Après analyse avec François, il s'avère que le script ccm.sh
ne contient aucune variable start stop etc ..., ceux ci sont dans le
fichier ccmunix.js (javascript)
(/appli/priceminister/bo/bobje/setup/jscripts/ccmunix.js) Dans ce fichier js on a pour -start else if (objArgs.Item(i).toLowerCase() == "-start") { //Next argument is the server type to start if (objArgs.Count() > i+1) { i=i+1 serverStart(objArgs.Item(i)) } } En résumé, je pense qu'en modifiant les scirpts d'origines (en les envelloppant par pmbi --start ou autres) on risque de passer à côté de quelque chose , d'un paramètre mal connu et engendrer des disfonctionnement système. Je pense qu'on devrait rester sur le document de base fourni par BO. Par contre pour la rotation de log, on peut y coller le mécanisme actuel sur les SA qui déplace les vieux fichiers sur le SHARE NFS junon |
| Commentaire de Ranto Andriambololona [ 30/mars/06 16:47 ] |
|
François , peux tu réfléchir si le changement du user bi en pmbi peut ètre problématique pour l'application bi ? - L'objectif est de recréer le user bo en pmbi avec les mêmes id et gid (1527:502) - ensuite faire un chown -R pmbi:adminpm sur les répertoires de l'appli - tests |
| Commentaire de Ranto Andriambololona [ 05/avr./06 17:37 ] |
|
On avance .... ci -après les résultat d'une première version d'un pmbi --status, --start, --stop sur PERIGNON STATUS [bo@perignon bobje]$ ./pmbi --status BI is running ( 13 processes) ... ARRET [bo@perignon bobje]$ ./pmbi --stop You are about to stop BI Type 'YES' to confirm: YES Stopping BI ... Using CATALINA_BASE: /home/bo/bobje/tomcat Using CATALINA_HOME: /home/bo/bobje/tomcat Using CATALINA_TMPDIR: /home/bo/bobje/tomcat/temp Using JAVA_HOME: /home/bo/bobje/jdk Stopping all... 2006-04-05 17:34:12 - [ ] BI stopped DEMARRAGE [bo@perignon bobje]$ ./pmbi --start Starting BI ... Starting all servers... Starting pageserver... Starting cacheserver... Starting input... Starting output... Starting destjobserver... Starting lovjobserver... Starting reportjobserver... Starting programjobserver... Starting webijobserver... Starting eventserver... Starting ras... Starting webi... Starting cms... Using CATALINA_BASE: /home/bo/bobje/tomcat Using CATALINA_HOME: /home/bo/bobje/tomcat Using CATALINA_TMPDIR: /home/bo/bobje/tomcat/temp Using JAVA_HOME: /home/bo/bobje/jdk Creating session manager... Logging onto CMS... 2006-04-05 17:34:57 - BI started Il reste la partie --force et l'archivage des logs |
| Commentaire de Ranto Andriambololona [ 11/avr./06 14:31 ] |
|
Archivages des logs en place ... les logs dans /home/bo/logs vieux de plus de 30 jours sont archivés (zippé et déplacé) dans /data/priceminister/pmshare/exploit/logs/bi/ sur le SHARE NFS |
| Commentaire de Ranto Andriambololona [ 11/mai/06 16:29 ] |
|
Le pmbi --stop --force est en place sur TELLUS pour la prod, il suffit juste de copier le script pmbi (sur perignon dans /home/bo/bobje) vers le serveur bi de PROD. |
| Commentaire de Ranto Andriambololona [ 11/mai/06 17:41 ] |
|
je voulais dire en place sur Perignon |
| Commentaire de Antoine Koener [ 19/janv./07 11:27 ] |
|
Salut, Dis moi ce Jira est encore ouvert, est-ce qu'on peut le fermer ? Merci :) |
[APP-29785] Problème possible sur le tag PAIEMENT REUSSI Création: 04/juin/10 11:52 Mise à jour: 30/sept./10 16:34 Résolue: 23/sept./10 11:12 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 78.0.0 (CTN-TU) |
| Type: | Bogue | Priorité: | Bloquant |
| Rapporteur: | Jonathan Gorges | Attribution: | Swan Desportes |
| Résolution: | Aucune correction envisagée | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM: | *** RESERVE *** |
| Classif FONC: | webanalytics |
| Description |
|
Bonjour,
Nous sommes actuellement en période de bilans et agrégeons donc les données nécessaires de nos différentes sources (Xiti, BI,...) pour sortir les résultats du mois de mai. Nous constatons des évolutions très "louches" voir impossibles des Paiements Réussis sur plusieurs de nos canaux marketing. Sur l'affiliation par exemple (groupe de tracking Affiliationx - Zanoxx - Cibleclickx dans Tracking 1) -> +69% de PR (source Xiti) entre avril et mai alors que le VA augmente de +20% (source BI) -> Cette augmentation est généralisée sur les 3 groupes de tracking (+65% sur Affiliationx, +76% sur Zanoxx, +56% sur Cibleclikx) Sur les souhaits Les PR ont été multiplié par 2 alors que le business des souhaits est plutôt stagnant entre avril et mai. Sur la news culturelle +90% de PR d'un mois sur l'autre... Pourriez-vous svp vérifier si quelque chose a perturbé le tag PR sur mai ? Merci d'avance pour votre aide. Jon |
| Commentaires |
| Commentaire de Jérôme Viviès [ 04/juin/10 11:59 ] |
| Jira ouvert par erreur en DEC - je l'ai passé en app et attribué au pôle CTN sur demande de Jonathan. |
| Commentaire de Swan Desportes [ 04/juin/10 15:31 ] |
|
Pour l'instant, je vois deux pistes : - des bourdes sur la table des comptes contact. Visiblement, dans le cadre du jeu concours liste mariage, les importes de contacts ont été erratiques. Néanmoins, il ne semble pas qu'il y ait eu de comptes détruits ou réinitialisés. - des désactivation de gros tracking. Notamment, je vois que mediastay a été désactivé ? Est ce que c'est récent ? Est ce que vous en avez désactiver d'autres ? Merci |
| Commentaire de Swan Desportes [ 23/sept./10 11:12 ] |
|
Le problème de la nouvelle page de login avec captation de l'email et donc création de contacts.
Les courbes sont très claires; On voit bien que ça concorde. Pour palier à ce problème, un projet est prévu dans le roadmap TX pour demander aux internautes de réutiliser leurs anciens comptes plutôt que d'en créer de nouveaux. |
[BIN-249] comptage des paniers et coupons sur le mail automatique M2bis Création: 19/déc./06 18:07 Mise à jour: 14/sept./07 17:33 Résolue: 19/janv./07 17:42 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Alexandra Viravaud | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Agathe, Nous avons un pb avec l'un de nos mails automatiques proposant un coupon. http://www.priceminister.com/newsletter/2005-01-18-auto-n2b/Encore-valable.htm D'après les rapports que nous utilisons sur BI, nous avons 5665 coupons utilisés (code promo WELCQTZGC) et 5163 paniers (tracking 727142) issus de ce même message. Il semble qu'il y ait vraissemblablement une erreur car sur les autres messages du même type nous avons globablement 2 fois plus de paniers que de coupons utilisés. Tu peux regarder ca ? Merci Alex |
| Commentaires |
| Commentaire de Agathe Remy [ 20/déc./06 14:49 ] |
|
Alex, Pourrais-tu nous communiquer le nom des rapports utilisés pour obtenir ces chiffres? Merci:-) Agathe |
| Commentaire de Alexandra Viravaud [ 20/déc./06 16:01 ] |
|
Purchase tracking by month pour les paniers et bilan coupon par mois pour les utilisations de coupon (dans Olivier). |
[EXP-3097] minitor : manque une alerte (mod_jk) sur aricia ? Création: 18/déc./06 14:58 Mise à jour: 25/juin/07 19:00 Résolue: 24/mai/07 16:15 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Justin Ziegler | Attribution: | Ange Ferrari |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
on n'a jamais recu d'alerte de ce genre provenant d'aricia... ----- Message transféré ---- De : "phaeton.minitord@priceminister.com" <phaeton.minitord@priceminister.com> À : Hostmaster Priceminister <hostmaster@priceminister.com>; Supervision Priceminister <supervisionpm@yahoo.fr>; CMS France <alertepm@infogerance.cms-france.net> Envoyé le : Vendredi, 15 Décembre 2006, 16h40mn 15s Objet : [minitord] mod_jk reports server down (Fri Dec 15 16:40:15 2006) phaeton Fri Dec 15 16:40:15 2006 mod_jk reports server(s) down : bi minitord version 2.2.0 |
| Commentaires |
| Commentaire de Justin Ziegler [ 02/mars/07 12:18 ] |
|
Est ce que ce pb persiste ? peut on fermer le jira ? |
| Commentaire de Justin Ziegler [ 02/avr./07 10:25 ] |
|
Je constate que ce pb n'est toujours pas resolu. Cela devient genant dans la mesure ou cupidon et phaeton vont bientot etre mis a la retraite... |
| Commentaire de Justin Ziegler [ 02/avr./07 10:25 ] |
| Quelle solution peut on envisager ? |
| Commentaire de Ange Ferrari [ 02/avr./07 18:06 ] |
|
Les amis de mod_jk ont eu la bonne idée de changer le format des LOGS Phaeton Error connecting to tomcat. Tomcat is probably not started or is listening on the wrong port. worker=saturne failed Aricia (saturne) Connecting to tomcat failed. Tomcat is probably not started or is listening on the wrong port La solution est simple c'est migré dans le nouveau système de monitoring, corrigé sur minitord le temps que les alertes parviennent aussi à CMS depuis le nouveau systeme |
| Commentaire de Ange Ferrari [ 24/mai/07 16:15 ] |
| alerte en place |
[EXP-4598] TERRA - la table PRD_EVENT n'est pas correctement alimentée Création: 30/oct./08 14:17 Mise à jour: 30/oct./08 14:25 Résolue: 30/oct./08 14:25 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Flux |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Bloquant |
| Rapporteur: | Dalila Belkebir | Attribution: | Ayoub Benseghir |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
la table PRD_EVENT n'est pas renseignée convenablement : il y a juste les colonnes PRD_EVENT_ID et PRDUCT_ID qui sont alimentées. Pourtant dans la base d'archive, la table semble correctement alimentée en données. Nous devons travailler sur un projet de récupération dans le BI des données évènements sur PRD_EVENT, PCH_EVENT et WALLET_EVENT. Merci donc de corriger l'alimentation sur TERRA de la table PRD_EVENT et de vérifier que les autres tables sont OK. Merci. Dalila. |
| Commentaires |
| Commentaire de Ayoub Benseghir [ 30/oct./08 14:25 ] |
| Les autres champs de prd_event étaient volontairement ignorés. Ils seront maintenant importés (prévoir une prolongation du temps d'alimentation). |
[BIN-471] [Marketing] : Rapport coupon Création: 05/août/08 10:27 Mise à jour: 06/août/08 15:21 Résolue: 06/août/08 15:21 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Thomas Beylot | Attribution: | Dalila Belkebir |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Hello Nous avons depuis un certain temps créé quelques nouveaux coupons. Or les rapports de coupon sur BI ne les prennent pas forcément en compte. J'ai essayé de retoucher la requête =Si([Coupon secret name] DansListe ("ALPACINO";"CORLEONE");"PARRAINAGE";Si((Comparer([Coupon secret name];"WELC*")) OR (Comparer([Coupon secret name] secret name];"VAL*"));"AUTOMATISATION";Si(Comparer([Coupon secret name];"*AUTO*");"AUTOMOBILE";"AUTRES"))) mais devant mon manque de connaissance face à cette pbtique je me décide à faire appel à l'expert :) merci thomas |
| Commentaires |
| Commentaire de Agathe Remy [ 05/août/08 11:58 ] |
|
Thomas, Peux-tu nous donner le chemin d'accès et le nom du ou des rapports concernés? Merci. Agathe |
| Commentaire de Dalila Belkebir [ 06/août/08 15:21 ] |
|
Vu avec Thomas. La requête est donc à modifier directement dans BO. Dalila. |
[BIN-479] [Cobranding] : Arrêt du cobranding ACF au 31/08/2008 Création: 02/sept./08 11:14 Mise à jour: 14/oct./08 11:08 Résolue: 06/oct./08 16:00 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Partners |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Agathe Remy | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour, ACF souhaite arrêter notre partenariat. Il a pris fin officiellement le 31/08/08. Pouvons-nous activer la procédure de désactivation du cobranding ? Le JIRA est ici : http://pricejira.lan/browse/APP-21944 1 / Faire rediriger http://www.radindesbois.com/ vers PM (Exploit) 2 / Arrêter les rapports BI hebdo et mensuel (Décisionnel) 3 / Envoyer un email à tous les comptes pour leur dire qu'ils peuvent continuer à acheter sur PM (Marketing) Souhaitez-vous faire une réunion à ce sujet ? Ghislain |
| Commentaires |
| Commentaire de Agathe Remy [ 03/sept./08 15:42 ] |
|
Rien dans le contrat : on peut intégrer nos « radin des bois
» (après l'envoi d'un mail quand même, comme à chaque fois ou selon les
process habituels - c'est quoi ?) Benoit |
| Commentaire de Dalila Belkebir [ 03/sept./08 17:36 ] |
|
Agathe, 1 OK => j'ai suspendu les planifications de rapports. 2 il faut donc modifier le flux PN_DATA pour les ajouter dans les BRAND_ID sélectionnés ? 3 ON peut transmettre dès aujourd'hui (ou après le mail MKT ?) les infos à MM ? Juste l'info sur la fin du cobranding ou aussi leur communiquer les données (et donc modifier le flux MM ?) ? Merci de ton retour. Dalila. |
| Commentaire de Dalila Belkebir [ 30/sept./08 10:30 ] |
|
Cyril, Voici la modification à mettre en place - pour ce soir ou demain matin en prod sur le flux mensuel - pour jeudi 02/10 au soir sur le flux quotidien Dans le mapping des données pour PN_DATA, il faut : - ajouter les anciennement co brandés "radins des bois" (ou 'ACF') dont le brand_id = 290 dans le flux mensuel - ajouter les anciennement co brandés "radins des bois" dont le brand_id = 290 dans le flux quotidien - tester en dev Merci. Dalila. |
| Commentaire de Cyril Tanneau [ 06/oct./08 16:00 ] |
|
Bonjour, les améliorations ont été apportées conformément à la demande. Les développements ont été effectués en DEV, testés et déployés en production. Les "Radins des bois" (brand_id=290) figuraient bien dans le fichier mensuel généré le 02/10/08 ainsi que dans l'UPDATE journalier adressé à PNDATA. Merci, Cyril |
| Commentaire de Agathe Remy [ 14/oct./08 11:08 ] |
|
Les comptes cobrandés ACF ont bien été insérés aux flux Pn Data qui se sont générés sans erreur en octobre 2008. Agathe |
[BIN-539] [Back-Office] : Demande de dimension pour les compensations Création: 07/janv./09 12:01 Mise à jour: 25/févr./09 11:59 Résolue: 07/janv./09 18:48 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | BackOffice |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Nouvelle fonctionnalité | Priorité: | Critique |
| Rapporteur: | Cedric Favero | Attribution: | Julien Girardet |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
J'ai une demande un peu urgente. Est-il possible facilement de sortir un rapport sur le nombre de compensations par virement (les anciennes) sur 2008 par date. Je n'ai trouvé çà que dans l'univers ITEM mais on a uniquement le nombre d'items payés ou les montants. Me faudrait donc un - compensation count - compensation creation date Et est-il possible aussi de faire la distinction entre les virements nationaux et internationaux au sein de BI (car je vois simplement les type cheque, transfer et pmv) ? Par le pays? Merci. |
| Commentaires |
| Commentaire de Cedric Favero [ 07/janv./09 12:01 ] |
|
En fait c'est pour Philippe avant la fin de la semaine. Si compliqué , je le fais à la main à partir de nos archives... Merci. |
| Commentaire de Cedric Favero [ 08/janv./09 15:09 ] |
|
Ca demande une mise en production c'est çà? Car je ne vois rien de nouveau dans l'univers en question.. |
| Commentaire de Julien Girardet [ 08/janv./09 15:12 ] |
|
Ca arrive bientot ! d'ici ce soir maximum. Julien. |
| Commentaire de Julien Girardet [ 08/janv./09 16:22 ] |
|
C'est bon, les nouveaux objets sont livré en Production. Donc tu trouveras dans la classe Compensation de l'univers ITEM (France & Espagne) les objets suivant : - Compensation creation date - Compensation creation month - Compensation creation year - Compensation count ainsi que des filtres : - Select compensation creation date period : permet de selectionner une periode de creation de compensation - Select compensation creation year : permet de selectionner une année de création de compensation Concernant la distinction entre les virements nationaux et internationaux : On peut distinguer les compensations de type virement national/ international en regardant la dimension "User bank country" (= pays de banque du virement) Mais il n'exsite pas de type "virement international" pour les compensations Par contre au niveau de l'opération (rattaché à la compensation) le type permet de distinguer les virements internationaux, voir la dimension Operation type label (Item/Item operation) Peux tu valider ces nouveaux objets BO ? Julien. |
| Commentaire de Agathe Remy [ 28/janv./09 20:07 ] |
|
Bonsoir Cédric, Peux-tu valider cette demande afin que nous puissions la clôturer? Merci! Agathe |
| Commentaire de Cedric Favero [ 29/janv./09 12:12 ] |
|
Oui pardon, j'avais commencé mais pas fait le tour de tout. Tout semble ok , çà fonctionne bien et plutot tres rapide. Coté opérations PMV , je pense qu'on a ce qu'il faut , meme si plutot dans USER ACCOUNT Merci beaucoup. |
[BIN-558] [Finance] : Rapport détaillé de suivi des opérations PMV Création: 19/févr./09 10:07 Mise à jour: 16/avr./09 09:26 Résolue: 01/avr./09 11:28 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Finance |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Agathe Remy | Attribution: | Julien Girardet |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
DMR - détail des opérations PMV 1.1.doc
|
| Pays: |
FRA - France
|
| Description |
|
Afin de permettre à la comptabilité de guider le nettoyage
des opérations par le BackOffice, il est demandé de mettre en place un
rapport avec le détail des opérations PMV avec la sélection d'une
période de finalisation de l'opération ainsi que la sélection d'une ou
plusieurs causes. Ce rapport s'inspire du rapport Operation_Report.txt généré par l'ancien système. Une fois le détail des opérations disposible dans BI, ne pourront être conservés dans le rapport de l'ancien système que les soldes. Agathe |
| Commentaires |
| Commentaire de Dalila Belkebir [ 01/avr./09 11:28 ] |
|
Bonjour Claudie, Peux-tu STP vérifier et valider la demande pour clôture ? Merci. Dalila. |
| Commentaire de Dalila Belkebir [ 16/avr./09 09:26 ] |
|
JIRA validé le 16/04 par la DAF. Cdlt, Dalila. |
[BIN-553] [Back-office] Integration des coordonnées vendeur ? Création: 23/janv./09 09:58 Mise à jour: 24/sept./09 15:46 Résolue: 24/sept./09 15:46 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | BackOffice |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Cosmétique |
| Rapporteur: | Cedric Favero | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Dans l'univers USER ACCOUNT, on a differentes coordonnées: default adress payment address shipping address meeting address Mais depuis les modifs DEV faites cet été (inscription vendeur/ ouverture boutique..) , on parle maintenant de "coordonnées vendeur". A-t-on accès à cette table ou finalement est-ce simplement l'adresse de paiement qui a été renommée? Je crois qu'on a migré les adresses de paiement vers ces nouveaux champs mais du coup a-t-on accès à ces derniers dans le BI? Merci. |
| Commentaires |
| Commentaire de Cyril Tanneau [ 28/août/09 10:31 ] |
|
Bonjour Habib, suite à notre entrevue de cette semaine, as-tu besoin de plus d'informations à ce sujet? Le cas échénat, peux-tu fermer la demande? Merci, à ta dispo si tu as des questions. Cyril Tanneau |
| Commentaire de Cyril Tanneau [ 14/sept./09 16:12 ] |
|
Bonjour, pour revenir sur cette demande, toutes les informations relatives aux addresses sont désormais disponibles dans l'univers USER ACCOUNT, dans la classe User address. Quant au type d'addresse analysé dans la requête, celui-ci peut être sélectionné grâce au filtre "Select user address type". (Pour les "coordonnées vendeur", il faut utiliser la RETURN ADDRESS. ) Je reste à votre disposition pour toute question. Le cas échéant, pouvons-nous considérer cette demande comme clôturée? merci, Cyril |
| Commentaire de Habib-Sylvain Gourguet [ 24/sept./09 15:41 ] |
|
"Les adresses, c'était mieux avant." :-) Ok de notre côté, ce JIRA peut être fermé. Merci. |
[BIN-570] Comptage Opt-in femmes ESP Création: 17/mars/09 11:44 Mise à jour: 25/mars/09 14:22 Résolue: 17/mars/09 16:54 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Pierre-Emmanuel Bianchi | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ESP - Espagne
|
| Description |
|
Suite à la réalisation d'un comptage des opt-in femmes en
Espagne, je constate qu'il y a davantage de mails que de comptes. Or, il
devrait normalement y avoir plus de comptes que de mails, car il est
possible d'avoir plusieurs comptes avec la même adresse mail. Pourriez-vous en outre m'aider concernant le problème des users birth date (beaucoup de contacts apparaissant comme étant nés en 1900...)? Le rapport BI se trouve dans la session ur marketing (password: ant2oine), Mes dossiers/Favoris/Pierre-Emmanuel/Comptage Optin Partner. Merci d'avance. Cordialement, P-E |
| Commentaires |
| Commentaire de Agathe Remy [ 17/mars/09 16:51 ] |
|
Bonjour Pierre-Emmanuel, Je viens de regarder ton rapport et voici les réponses à tes questions : - comme expliqué par téléphone, il y a plus d'emails que de comptes dans le 2ème tableau (contrairement au 1er) parce que le contenu des colonnes est inversé : tu as l'indicateur "Subscriber email count" dans la colonne dont l'intitulé est "Subscriber count" et l'indicateur "Subscriber count" dans la colonne dont l'intitulé est "Subscriber email count"; - je ne comprends pas quel est ton problème avec les dates de naissances, surtout qu'elles n'apparaissent dans aucun des 2 tableaux. Je te propose donc de commencer par ajouter l'information puis de m'expliquer ce qui te semble incohérent. Pour info, comme discuté avec Charles vendredi, le filtre prédéfini "Not cheater" filtre les fraudeurs mais également les comptes contacts (prospects non inscrits). Ainsi, si tu veux les faire apparaître dans ton rapport, je t'invite à supprimer ce filtre dans la requête. Agathe |
| Commentaire de Agathe Remy [ 25/mars/09 14:22 ] |
|
Comme vu par Oral, la demande a été traitée. Agathe |
[BIN-580] [Back-Office] Univers Item - nécessité d'un Item claim creation date Création: 28/avr./09 15:31 Mise à jour: 13/mai/09 10:09 Résolue: 28/avr./09 16:21 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | BackOffice |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Cedric Favero | Attribution: | Agathe Remy |
| Résolution: | Invalid | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Dans l'univers Item, on a bien un: Item claim last date Item claim closing date => Pb: aucune ne renvoit les claims "créées". En fait çà ne ressort que les claims acceptées, pas les rejetées.. Du coup bcp de chiffres sont biaisés et on est obligés de se rabattre sur l'item capture date mais qui malheureusement est tres éloignée du "claim date" Il nous faudrait donc un item claim creation date (pour tout claim intervenue: créee, en cours, rejetée ....) Merci. |
| Commentaires |
| Commentaire de Agathe Remy [ 28/avr./09 16:21 ] |
|
Bonjour Cédric, "Item last claim date" est la date de dernière ouverture de réclamation. Il existe donc des transactions avec réclamations acceptées, rejetées, en cours de traitement ou créées ET une date de dernier dépôt de réclamation. En revanche, la dimension "Item claim closing date" étant la date de clôture de réclamation, les transactions ayant une date de clôture de réclamation sont généralement en statut définitif ("Acceptée" ou "Refusée"). Quoique si une nouvelle réclamation est ouverte sur ce même article, on aura une réclamation en statut "Crée" ou "En cours" avec une date de dernière ouverture de réclamation supérieure à la date de clôture de réclamation. Si tu n'obtiens que des réclamations acceptées, ton problème est ailleurs... A ta dispo si tu as des questions. Agathe |
| Commentaire de Cedric Favero [ 29/avr./09 09:38 ] |
|
Effectivement c'était mon item claim count qui ne ramenait que des claims acceptées. Avec un item count c'est bon. Par contre le défaut, c'est qu'une claim peut etre crée ,ouverte, fermée, réouverte lors de nos traitements et du coup çà crée un décalage. On ne stocke pas le claim creation date c'est çà? |
| Commentaire de Agathe Remy [ 29/avr./09 10:02 ] |
|
En effet, la date de 1ère ouverture d'une réclamation n'existe pas. Il faudrait demander aux Dévs de l'ajouter. Agathe |
[DEC-332] [1euro] développement rapport décisionnel Création: 26/avr./06 18:48 Mise à jour: 14/sept./07 14:38 Résolue: 13/juil./06 17:02 |
|
| Etat: | Fermé |
| Projet: | Reporting |
| Composants: | Executive |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Nouvelle fonctionnalité | Priorité: | Majeur |
| Rapporteur: | Martin Iacampo | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | 0 minutes | ||
| Temps consacré: | 1 jour | ||
| Estimation originale: | 1 jour | ||
| Pièces jointes: |
rapport décisionnel 1euro mini spécification fonctionnelle.doc
|
||||||||
| Liens des demandes: |
|
||||||||
| Description |
|
Pour faire suite à la demande de la DG d'un rapport décisionnel, un rapport décisionnel est demandé de l'équipe BI. Le format et contenu de ce rapport se trouve dans la pièce jointe, rapport décisionnel 1euro mini spécification fonctionnelle.doc (Les événements seront développés et stockés dans la base, voir JIRA En cas de question, s'adresser à MIA à partir du 09/05 ou à AFO si c'est plus urgent. |
| Commentaires |
| Commentaire de Martin Iacampo [ 23/juin/06 14:14 ] |
|
Mise à part un seul point (APP-10624) à étudier ultérieurement, le développement des évènements est terminé et devrait permettre le déblocage de cette demande. **L'activation de 1euro est prévu la première semaine de juillet, et il serait top si la mise en place du rapport décisionnel suivait derrière.** Restant à votre disposition si vous souhaitez faire un point avant de vous lancer. :-) |
| Commentaire de Cyrille Sarti [ 11/juil./06 16:55 ] |
|
Bonjour, Avez-vous convenu de la périodicité de ce rapport ? Bonne fin d'après midi, Annabelle. |
[BIN-548] [Sponsorship] : Rapport parrainage Création: 13/janv./09 16:05 Mise à jour: 18/nov./10 18:07 |
|
| Etat: | Ouvert |
| Projet: | Business Intelligence |
| Composants: | CRM |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Thomas Beylot | Attribution: | Julien Girardet |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
rapport-difference-nbacheteur-filleuls.xlsx
|
| Pays: |
FRA - France
|
| Description |
|
Hello je viens de me rendre compte que lorsque qu'on compare les deux rapports BI sur le parrainage (dans sponsorship, les rapports nommés Referred user activity by month et Referred sponsor activity by month) les chiffres ne correspondent plus trop depuis juillet 07. En effet je vois qu'on a plus de coupons utilisés sur les filleuls que de coupons filleuls utilisés. Or normalement les deux chiffres devraient être au moins égaux non ? il peut y avoir des filleuls actifs qui n'utilisent pas leur coupon mais à part ça je ne vois pas ce qui pourrait justifier l'écart ? à votre dispo pour en parler, ou JM pendant que je ne suis pas là. En pj un extract. thomas |
| Commentaires |
| Commentaire de Thomas Beylot [ 05/févr./09 10:52 ] |
|
Bonjour a t-on du neuf sur le sujet ? thomas. |
| Commentaire de Thomas Beylot [ 11/févr./09 18:27 ] |
|
hello, quelqu'un ? merci |
| Commentaire de Dalila Belkebir [ 11/févr./09 18:30 ] |
| y'a personne, sont tous partis aux soldes de soldes ;-) |
| Commentaire de Agathe Remy [ 09/mars/09 16:52 ] |
|
Bonjour Thomas, J'ai quelques incompréhensions vis-à-vis de tes constats?! - les indicateurs que tu compares (Nouveaux acheteurs et Coupons utilisés) me semblent provenir tous 2 du rapport "Referred user activity by month" et non de 2 rapports ("Referred user activity by month" et "Referral sponsor activity by month")?! - l'indicateur "New buyers" compte le nombre de nouveaux acheteurs dont le 1er achat a été capturé et dont le tracking du panier est celui d'un des mails de parrainage; - l'indicateur "Used coupons" compte le nombre de coupons filleuls utilisés au cours du mois Ainsi, si tu a plus de "Used coupons" que de "New buyers" à partir d'août 2007, cela peut signifier que les 1ers achats avec coupons de parrainage proviennent moins du clic sur le mail de parrainage. Peut-être d'un couponneur? Ou bien peut-être avez-vous changé les codes de tracking des mails de parrainage en juillet 2007? Agathe |
| Commentaire de Agathe Remy [ 09/mars/09 16:56 ] |
|
Pour info, les trackings définis pour calculer les nouveaux acheteurs sont les suivants : tracking_id;tracking_name;ust_group_id;report_period_code;creation_date;change_date 20;FILLEUL;168180;10;01/01/2001;01/01/2001 1772040;FILLEUL-relance;168180;10;06/03/2007;06/03/2007 1772041;FILLEUL-contextuel;168180;10;06/03/2007;06/03/2007 1772042;FILLEUL-contextuel-relance;168180;10;06/03/2007;06/03/2007 Agathe |
| Commentaire de Thomas Beylot [ 08/avr./09 09:27 ] |
|
Hello, Bon j'ai enfin pu me pencher sur ta réponse. En fait tu as raison je me suis mal exprimé, je compare des datas extraites du même rapport. Mais cela n'empêche pas que le chiffre se soit "retourné" depuis juillet 2007 (ça se confirme sur Q1 2009). Je comprends mieux pourquoi il peut être négatif (donc que le nb de coupons utilisés dépasse le nb de nouveaux acheteurs alors que c'est illogique au départ) car je ne savais pas du tout que le nombre de nouveaux acheteurs était indexé non pas sur le suivi de l'email (sans considération aucune pour le tracking, donc) mais sur le last tracking (qui est celui du premier achat) > je suis assez étonné de ce choix, d'ailleurs, que je trouve donc illogique mais j'imagine que c'est une contrainte technique ? Ceci étant, je me demande pourquoi la différence est positive (nb d'acheteur - nb de coupons utilisés sur les filleuls) jusqu'en juillet 07 et tout d'un coup négative depuis ? Aurait ce à voir avec la refonte du système de parrainage ? Vois tu une explication ? thomas. |
[APP-20323] Migration CBV 0-40: Probleme sur la mise à jour des montants Création: 18/avr./08 14:43 Mise à jour: 25/avr./08 11:39 Résolue: 25/avr./08 11:29 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Base de données |
| Affecte la/les version(s): | 20.0.0 |
| Version(s) corrigée(s): | 20.1.1 |
| Type: | Bogue | Priorité: | Bloquant |
| Rapporteur: | Romain Czornomaz | Attribution: | Clement Balay |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Site: | Prod | ||||||||
| Projets PM: | *** A PLANIFIER *** | ||||||||
| Description |
|
Comme vu tout à l'heure, Lors de la migration des données existantes en CBV interne, le montant de la prime Assur'one est passé de 0.62¿ à 0.13¿, mais la différence de ces 2 montants n' a pas été rajouté dans la Commission PriceMinister. Il est donc nécessaire de faire un script d'update pour ajouter les 0.49¿ au montants Commission PM pour chaque CBV migré. Lors de l'Update, il est nécessaire de mettre à jour la CHANGE_DATE des enregistrements à SYSDATE afin que nous puissions prendre en compte les changement au BI. Merci d'avance, Romain |
| Commentaires |
| Commentaire de Sébastien Aubert [ 21/avr./08 12:14 ] |
|
Script passé en integ --> Ok les garanties (internal)
créées avant le 08/04/2008 à 10h56 ont eu 0.49 ¿ ajouté à leur com
interne . Problème restant sur l'évenement : L'évenement doit être "Migration Corrective" et la descritpion doit être "Commission interne + 0.49" |
| Commentaire de Juan Luis Fajardo [ 24/avr./08 10:19 ] |
|
Panier 56852111 Est-il possible de corriger le montant? |
| Commentaire de Sébastien Aubert [ 25/avr./08 11:29 ] |
| Le script est passer hier en prod et a corrigé les paniers concernés. |
[Metatache CBV2] Implémentation de CVB V2
(APP-17836)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 17.0.0 |
| Version(s) corrigée(s): | 17.1.0 |
| Type: | Sub-improvement | Priorité: | Majeur |
| Rapporteur: | Renaud Dierickx | Attribution: | Renaud Dierickx |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM archivés: | Contrat "Bris et Vol" (Lot 2) |
| Description |
|
Demande de Steven : "on doit pouvoir revenir sur une rétractation. non pas pour revenir sur la décision de l'acheteur (c'est définitif) mais pour corriger une erreur d'un agent back office. L'état "retracted" s'il est définitif doit être intégré au rapport du bi pour remboursement pas assur'one. ça serait plus prudent d'utiliser les mêmes critères de temps que pour le "refunded" : si pas bougé au bout de trois mois" Je ne peux pour le moment pas faire ce développement car j'ai besoin du dev d'AFO qui est sur la branche V17_0_0. Ce jira me sert de mémo pour ne pas oublier de faire la demande de steven dès que possible. |
| Commentaires |
| Commentaire de Sébastien Aubert [ 19/oct./07 14:44 ] |
| ok en integ |
[APP-19807] Pb adresse dans "Mail à un ami" Création: 03/mars/08 10:53 Mise à jour: 16/avr./08 11:27 Résolue: 05/mars/08 10:13 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 19.0.3 |
| Version(s) corrigée(s): | 20.0.0 |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Christophe Garcia | Attribution: | Renaud Dierickx |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
screenshot-1.jpg
screenshot-1.jpg
|
| Pays: |
FRA - France
|
| Projets PM archivés: | Maintenance 20.x.x |
| Description |
|
Quand on envoie un mail à un ami, on va en base chercher le login de l'ami en fonction de l'email qui a été saisi. Pb : En revanche, on devrait essayer de trouver le compte le plus récent associé à cet email : en utilisant la "last_login_date" - c'est ce que fait le BI pour les mails MM (à vérifier avec eux) Exemple : http://bo.priceminister.com/user_back?action=userview&showeventothers=true&useraccountid=61114 |
| Commentaires |
| Commentaire de Renaud Dierickx [ 03/mars/08 11:03 ] |
| Etes-vous d'accord avec cette solution fonctionnelle ? |
| Commentaire de Quentin de Chivré [ 03/mars/08 18:45 ] |
| Ben oui c'est moi qui l'ait donnée :-) |
| Commentaire de Renaud Dierickx [ 05/mars/08 10:13 ] |
|
Parfait ! C'est corrigé. Cette fonctionnalité utilise un finder qui est également utilisé à d'autres endroits du site qui n'ont pas besoin du order by : les abo, l'inscription, ... Pour éviter les régressions au niveau des performances, j'ai créé un nouveau finder. |
[APP-20055] Regression 19.2.1. Certains évènements annonces ne sont plus créés. Création: 31/mars/08 15:35 Mise à jour: 25/avr./08 09:35 Résolue: 21/avr./08 11:04 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 19.3.0 |
| Version(s) corrigée(s): | 19.4.0 |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Edouard Gomez-Vaez | Attribution: | Manuel Sadok |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
APP-20055-done.xls
count_adv_event.xls
|
| Pays: |
FRA - France
|
| Classif1: | BP |
| Classif2: | trigger best-price |
| Projets PM archivés: | BP - Consolidation Produit / Annonce |
| Description |
|
Extraits d'une analyse BI. Voici les 4 évènements qui ne sont plus créés de puis le 26/03/2008 : 280 FRESHNESS_INFO 290 FRESHNESS_WARN 300 FRESHNESS_OUTDATED 410 PENDING_PUBLICATION Les évènements suivants sont aussi susceptibles d'être touchés, mais comme ils ont des volumétries très faibles, nous ne pouvons en être sûrs : 155 CLOSE_FROM_BO_MACRO_PRODUCT 500 PENDING_CONTRACT |
| Commentaires |
| Commentaire de Manuel Sadok [ 01/avr./08 11:50 ] |
| Ces 6 évènements sont de nouveaux générés. |
| Commentaire de Espérance Galouo-Lece [ 04/avr./08 11:00 ] |
| Done. |
[APP-21554] Raccourcis NpC : niveau 1 vers niveau N-X Création: 30/juil./08 18:16 Mise à jour: 24/sept./08 18:27 Résolue: 24/sept./08 17:06 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Référencement |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 30.0.0 (CAT-D) |
| Type: | Amélioration | Priorité: | Critique |
| Rapporteur: | Thierry Leforestier | Attribution: | Caroline Schinzel |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
illustration de la demande.jpg
raccourcis.png
|
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM: | *** RESERVE *** |
| Description |
|
Aujourd'hui, l'application permet d'effectuer des raccourcis
par le biais de l'option "afficher les fils", mais ne permet pas
d'obtenir une finesse sur le choix des catégories ou sous catégories a
remonter en raccourcis. il faudrait donc qu'une option "raccourcis" soit disponible dans le BO sur le noeud concerné pour ajouter manuellement un raccourci (par option) avec la liste des sous catégories dans un select. une fois sélectionné, ce noeud apparait sous la catégorie (voir PJ). N'hésitez pas en cas de question |
| Commentaires |
| Commentaire de Thierry Leforestier [ 30/juil./08 18:17 ] |
| Cette modif doit être dispo surtout pour l'espagne (dans le cadre du chantier optimisation Nav Par Cat) |
| Commentaire de Benoît Bourdon [ 31/juil./08 10:16 ] |
|
Ce que je comprends de la demande : 1- Actuellement on peut faire des raccourcis d'un niveau N à N-1 et c'est tout 2- On ne peut pas faire de raccourcis vers 1 seule sous-cat mais vers toutes les sous-cat "soeurs" en même temps ---> Cette evolution sera uniquement appliquée pour l'Espagne (qui va rester encore longtemps en NPC et qu'il faut optimiser d'un point de vu REF sans attendre les futures NpF) (je remet le contexte, car il n'était pas prévu de retoucher un jour la NpC .. il était plutôt prévu de la laisser mourir tranquillement ...) --> Le but donc permettre la création de raccourcis (à peu de frais) à partir d'un noeud donné : - Vers n'importe quelle sous catégorie (une par une) de n'importe quel niveau de profondeur - Ces liens seront fait uniquement pour les apsects référencement -> il seront systématiquement crawlable (ie : on ne rajoutera pas un paramètre brouillable oui / non) |
| Commentaire de Benoît Bourdon [ 31/juil./08 10:17 ] |
| PS : il faut utiliser le style existant pour les raccourics (pas besoin de maquettes) |
| Commentaire de Martin Sudmann [ 25/août/08 15:11 ] |
|
Je reviens sur le "à peu de frais": la solution bon marché serait de régler ça via des paramètres dans la conf ; seul bémol : on ne peut pas varier l'ordre d'affichage. On peut appliquer un tri automatique (par ordre alphabétique, par exemple), mais si on a "otras" et "zorro", "otras" viendrait forcement en premier. Thierry, pourrais tu voir avec les commerciaux / les params si c'est ok pour eux ? Si le dev devient plus complexe que ça, le Jira sortira probablement de la CAT-D. |
| Commentaire de Thierry Leforestier [ 25/août/08 15:30 ] |
|
C'est validé avec les commerciaux, l'ordre d'affichage ne leur pose pas de problème. D'autant que nous ne ferons que très rarement ressortir otros a mon avis, le tri, quel qu'il soit, restera donc globalement pertinent. Thierry |
| Commentaire de Martin Sudmann [ 25/août/08 16:35 ] |
|
ok, l'implémentation sera donc à priori: un paramètre sur le noeud parent NpC permet de pointer sur une autre catégorie NpC pour la remonter en tant que sous catégorie. L'ordre des catégories remontées sera dans tous les cas l'ordre alphabétique et n'est pas, comme dans les vraies sous-catégories, configurable. Les liens remontés seront toujours crawlables, puisque c'est une demande du référencement. |
| Commentaire de Martin Sudmann [ 29/août/08 16:31 ] |
|
j'ai regardé un peu ; grâce au sublime code de la NpC (bien
structuré et maintenable; je rigole.) ce n'est pas facile à implémenter. Je le transfère à MOD, mais ne ne peux pas garantir que ça passe en cat D. |
| Commentaire de Martin Sudmann [ 29/août/08 16:31 ] |
| voir si c'est faisable sans trop dégrader le code (même si c'est la NpC ; il faut quand même la garder maintenable). |
| Commentaire de Caroline Schinzel [ 19/sept./08 11:41 ] |
|
L'implémentation est bien celle décrite par Martin un peu plus haut (25 août - 16h35) Les sous-catégories remontées s'affiche à la suite des fils du noeud parent s'ils sont affichés (Combinaison d'affichage des deux modes de remontée) |
| Commentaire de Benoît Bourdon [ 19/sept./08 11:47 ] |
|
Cool :-) Je peux tester quelque part et montrer ça au Ref ? |
| Commentaire de Christophe Garcia [ 24/sept./08 16:40 ] |
|
Aucune vérification n'est faite sur le fait que l'on pointe bien vers une sous-catégorie. Voir URL : http://www.es.integ/navigation/default/category/root_games Le lien Bateria n'est pas une sous-cat de Consolas |
| Commentaire de Martin Sudmann [ 24/sept./08 17:06 ] |
|
le développement a été demandé en tant qu'implémentation LIGHT. La solution choisie (et donc la possibilité de pointer vers d'autres sous catégories) a été discuté et acceptée par le BO. Les référencement est conscient qu'il faut faire attention de bien choisir le lien sur lequel ils pointent. |
[APP-24987] Fiche sinistre : le passage à l'état "Remboursé" ne fait rien Création: 17/avr./09 17:12 Mise à jour: 28/juil./09 10:27 |
|
| Etat: | Ouvert |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Marc-Antoine Decreton | Attribution: | Steven Harel |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Projets PM: | *** CHASSE *** |
| Description |
|
Sur l'écran de détail d'un sinistre, il est possible de changer l'état du sinistre. Le passage à l'état "Remboursé" ne fait absolument rien. J'ai modifié ce comportement en affichant le message suivant : "Le passage du sinistre dans l'état Remboursé n'est pas possible en mode manuel" (voir Aujourd'hui, le passage à "remboursé" ne se fait que par le biais de batchs qui effectuent des actions supplémentaires (crédit sur le PMV, envoi de mail à l'utilisateur...). Doit-on garder le comportement actuel (interdire le passage manuel à "Remboursé"), ou effectuer une autre action ? |
| Commentaires |
| Commentaire de Emeric Teil [ 29/mai/09 11:02 ] |
| Cedric, un avis la dessus ? |
| Commentaire de Cedric Favero [ 02/juin/09 18:29 ] |
| Je regarde çà, çà me parle pas vraiment. |
| Commentaire de Emeric Teil [ 27/juil./09 09:49 ] |
| Du nouveau ? |
| Commentaire de Cedric Favero [ 28/juil./09 10:03 ] |
|
A confirmer avec Steven mais effectivement ne sert à rien de
conserver l'état "remboursé" dans le menu de selection manuelle si la
seule façon d'arriver à un état remboursé correct est apres le passage
d'un batch. suffit donc de supprimer cet état de cette liste. |
| Commentaire de Emeric Teil [ 28/juil./09 10:05 ] |
|
OK merci ! Steven, ok avec ça ? NB : techniquement reste à voir si cela est possible... |
| Commentaire de Steven Harel [ 28/juil./09 10:27 ] |
| on peut garder le comportement actuel. pas utile de modifier quoi que ce soit. |
[APP-28650] [LPS] Mauvaise initialisation du formulaire de Mev Création: 09/mars/10 11:38 Mise à jour: 04/mai/10 09:48 Résolue: 17/mars/10 14:46 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 63.0.3 |
| Version(s) corrigée(s): | 68.0.0 (VEN-B) |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Jean-Sébastien Franck | Attribution: | Jean-Sébastien Franck |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Projets PM: | MEV - Landing Page Scénarisée | ||||||||
| Navigateur: | Tous | ||||||||
| Description |
|
Lorsqu'on est sur la proposition d'amélioration d'annonce,
toute modification de la FP par le biais du lien "modifier l'annonce"
est prise en compte en base de données, mais lorsqu'on re-modifie
l'annonce, on retrouve les anciennes valeurs dans le formulaire. Pour reproduire le bug : 1) Créer un produit de type vêtement. On se retrouve sur la LPS avec une proposition d'amélioration d'annonce. 2) Cliquer sur "modifier l'annonce" (le lien bleu), changer des champs (par exemple la taille et le commentaire) puis valider la modification pour retourner sur la LPS 3) Cliquer sur "modifier l'annonce" et constater que les champs ont leurs anciennes valeurs et non pas les valeurs qui ont été modifiées en 2) |
| Commentaires |
| Commentaire de Jean-Sébastien Franck [ 17/mars/10 14:46 ] |
| Les données du formulaire de mise en vente n'étaient pas correctement insérées en session. Problème corrigé. |
[APP-15148] Activation de l'inventaire lors d'une mise en vente auto? Création: 16/févr./07 16:26 Mise à jour: 25/juin/07 18:49 Résolue: 12/avr./07 18:37 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Annonces, Inventaire |
| Affecte la/les version(s): | 12.0.2 |
| Version(s) corrigée(s): | 14.0.0 |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Cedric Favero | Attribution: | Marc Cacheiro |
| Résolution: | Invalid | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Site: | Prod |
| Description |
|
Lorsque l'on crée un compte et que l'on met une voiture en
vente , on dispose bien d'une annonce visible dans l'espace "vendeur
auto" et mes annonces auto en ligne mais pourtant l'inventaire n'est
toujours pas actif et on ne peut donc accéder directement à son annonce
par ce biais. On a toujours le message "pas encore vendeur" et aucune rubrique dispo en dessous d"espace vendeur" dans la colonne de gauche. Si le fait de passer une annonce auto met le compte en visiblité 1 (est-ce bien le cas?) , l'inventaire ne devrait-il pas etre activé dans la foulée? |
| Commentaires |
| Commentaire de Patrick Condevaux [ 16/févr./07 18:13 ] |
|
Dans ce cas, les annonces auto sont accessibles dans la rubrique Mes annonces Auto en ligne dans la catégorie Vendeur Auto |
| Commentaire de Nicolas Chauveau [ 26/févr./07 10:44 ] |
| Est-ce le comportement prévu ou une amélioration ? |
| Commentaire de Marc Cacheiro [ 12/avr./07 18:37 ] |
| l'inventaire auto est spécifique, pas besoin de l'activer pour faire apparaître les annonces... |
[APP-19665] [Mots clés / Surveillance vendeur] Dectection du numéro de compte renseigné avec velocity? Création: 19/févr./08 16:52 Mise à jour: 02/juin/09 16:51 Résolue: 08/avr./09 12:10 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Back-Office |
| Affecte la/les version(s): | 19.0.1 |
| Version(s) corrigée(s): | 47.0.0 (TX-G) |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Cedric Favero | Attribution: | Dispatcher (Pôle TX) |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
rib.JPG
screenshot-1.jpg
|
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM: | *** RESERVE *** |
| Classif FONC: | CoSAV |
| Description |
|
Afin de mieux pouvoir retrouver des fraudeurs récidivistes ,
il nous serait utile de pouvoir surveiller en velocity le numéro de
compte renseigné par un utilisateur. En effet , une personne essayant à de nombreuses reprises de faire des ventes frauduleuses a de fortes chances pour se faire payer de renseigner à chaque fois le meme numero de compte. Est-il possible d'appeler en velocity des données du USR_BANK_ACCOUNT ? Essentiellement le numéro de compte du vendeur (capture). Le but étant de faire passer en -1 celui qu'on aura détecté par ce biais (surveillance vendeur). |
| Commentaires |
| Commentaire de Geneviève Beaujard [ 04/mars/08 16:32 ] |
| rien a voir avec les produits, renault STP peux tu renseigner cedric. |
| Commentaire de Emeric Teil [ 27/mars/08 18:51 ] |
| A prendre en compte dans les besoin de mot clefs pour l'Automatisation ? |
| Commentaire de Cedric Favero [ 28/mars/08 09:12 ] |
|
pour moi il s'agit plus de detecter des fraudeurs
récidivistes par leur numero de compte (detection et passage du compte
en -1) mais je vois avec steven si c'est egalement un besoin concernant l'automatisation des opérations de débit. |
| Commentaire de Emeric Teil [ 28/mars/08 09:55 ] |
|
En fait je pensais que, si on a des coordonnées bancaires
qui nous permettent de détecter des fraudeurs, il serait potentiellement
un plus de les ajouter également au niveau des bordereaux afin de
mettre systématiquement les opérations correspondantes en Observation. De plus, au niveau des opérations cela ne nous "coute pas très cher" car : -> L'objet "opération" sera dans le contexte velocity" -> Les coordonnées de paiement sont inclues dans l'opération depuis la Centralisation du PMV (avant elles étaient incluent dans l'utilisateur) -> On aura donc les coordonnées utilisées pour l'opération dans le contexte velocity utilisé pour les mots clefs sur les bordereaux |
| Commentaire de Cedric Favero [ 28/mars/08 10:15 ] |
| je mets steven en copie |
| Commentaire de Cedric Favero [ 23/mai/08 10:18 ] |
|
Demande intégrée dans le projet automatisation des
opérations de débits , il est possible de surveiller des informations
bancaires avec la table opération (surveillance debits). Par contre ma demande initiale concernait les surveillance vendeur , et il me faudrait donc pouvoir , pour ce type de mot clé, acceder en velocity à la table USR_BANK_ACCOUNT Merci. |
| Commentaire de Emilien Guichard [ 02/avr./09 18:17 ] |
| Quelles sont les coordonnées bancaires auxquelles on doit donner accès, celles de débit, celles de crédit ou les 2 ? |
| Commentaire de Cedric Favero [ 03/avr./09 09:08 ] |
|
Celles de débit suffisent. Ca peut etre le RIB, l'IBAN ou encore l'adresse postale du cheque. |
| Commentaire de Clement Balay [ 07/avr./09 12:16 ] |
|
En fait les infos étaient déjà présentes, nous avons quand même rajouté deux méthodes pour simplifier leurs accès: a partir d'un objet Operation, vous pouvez récupérer un objet AddressFormat ou BankAccountFormat de cette manière: - $operation.getAddressFormat() - $operation.getBankAccountFormat() A partir de là pour récupérer l'adresse formattée vous pouvez faire: - $operation.getAddressFormat().getFullFormatedAddress() Pour récupérer le code postal: - $operation.getAddressFormat().getStrZipCode() Pour récupérer le compte banquaire formatté: - $operation.getBankAccountFormat().getFormatedBankAccount() Pour récupérer l'IBAN - $operation.getBankAccountFormat().getIban() Pour récupérer le RIB - $operation.getBankAccountFormat().getRibAccountNumber() |
| Commentaire de Cedric Favero [ 07/avr./09 12:20 ] |
|
Ok sauf que pour la surveillance vendeur c'est dans le contexte $user qu'il me les faut.. $operation , ce n'est que lors d'un crédit/débit. |
| Commentaire de Clement Balay [ 08/avr./09 12:10 ] |
|
Ok, done, De plus j'ai rajouté l'outil de visualisation du contexte velocity pour le mot clé "surveillance vendeur" dans la page annonce, comme cela tu pourras voir un nouvel objet: bankAccount |
| Commentaire de Cedric Favero [ 08/avr./09 16:28 ] |
| Je peux voir où à quoi çà ressemble? |
| Commentaire de Clement Balay [ 10/avr./09 16:37 ] |
| sur devtest1 |
| Commentaire de Emilien Guichard [ 15/avr./09 09:59 ] |
| Recette OK en DEV |
[IMP-6754] ALIBRIS: confcall avec commerciaux Création: 13/août/10 11:32 Mise à jour: 13/août/10 14:31 Résolue: 13/août/10 11:34 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Demande commerciale |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Laurent Payot | Attribution: | Laurent Payot |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Login: | ALIBRIS |
| Séparateur: | N/A |
| Type de traitement: |
N/A
|
| Description |
|
Confcall de 17h à 18h30 avec les IT de ALIBRIS. Le pro qui
agrège diffèrents partenaires (un peu comme neteven) à 160 Millions
d'annonces, et dans certaines périodes critiques comme Noël jusqu'à 35%
des annonces peuvent être mises à jour quotidiennement (prix). Compte tenu des limitations techniques en termes de volume de traitement il faudra repartir les annonces du pro sur différents comptes, et limiter le nombre d'annonces total. Malgré tout pour l'instant le partenaire est trop gros pour être intégré, les commerciaux vont voir les différentes possibilités avec Justin. Une quantification de la capacité de traitements des imports va être effectuée par Fotigui en utilisant le BI. |
| Commentaires |
| Commentaire de Laurent Payot [ 13/août/10 14:31 ] |
|
De : Jeremy Pallot [mailto:jeremy.pallot@priceminister.com] Envoyé : vendredi 13 août 2010 14:41 À : 'Pam Nice'; 'Gael Seguillon' Cc : 'Brian Elliott'; 'Dave Rees'; 'Laurent Payot'; 'Jérôme Viviès' Objet : RE: Notes: PriceMinister and Alibris, August 12, 2010 Hello Pam, It was really nice talking to you yesterday. I am glad that could have such a productive conversation. I have upgraded your Uk account to the professional status. I confirm that all the summary of yesterday's phone call are accurate. ACTIONS and NEXT STEPS: ¿ ACTION: PriceMinister to estimate catalog file size to Alibris. Pam to set up FTP. PriceMinister to provide Alibris with Google Feed for catalog. Laurent will come back to you on the catalog maximum authorized size per FTP. Gaël/Myself will come back to you in regards to the Google feeds. It may take a up to a week. ¿ ACTION: PriceMinister to make recommendation to Alibris on the optimal account configuration: o Number of accounts. o Max # of listings per account. o Max and recommended file sizes for upload, adds, deletes, updates. Laurent will come back to you in regards to all the FTP performance indicators. ¿ ACTION: PriceMinister to send a shipping file with standard shipping prices, methods, and times. Please find enclosed the shipping cots refund grid per country. The values in red are what is paid by the customer and the values in black are what is refunded to the pro seller. ¿ ACTION: Pam to set up test account at PriceMinister. Jeremy will be the primary account manager contact with Laurent supporting. Note: we may use standard seller agreement, or, if necessary, request a custom contract. I will be your account manager and Laurent your IT support. On the legal side we are open to both solutions, you can on our Uk site read our general conditions. If you need a customized contract, I will ask my legal team to contact you. ¿ ACTION: Pam to arrange follow up meeting for next Thursday, 7PM Paris time, 30 mins so we can see how things are progressing. I will be next week out of the office on a business trip and can therefore not attend the meeting. Would it possible to postpone the meeting in two weeks? I remain at your disposal if you have any questions. Kind regards, Jeremy PriceMinister.com Jérémy Pallot Key Account Manager Northern Europe 57 Bvld de la Villette F- 75010 Paris France jeremy.pallot@priceminister.com Tel : +33 (0) 1 42 78 95 48 Fax : +33 (0) 1 42 72 80 61 UST: FR23432647584 De : Pam Nice [mailto:pamn@alibris.com] Envoyé : jeudi 12 août 2010 19:43 À : 'jeremy.pallot@priceminister.com'; 'gael.sequillon@priceminister.com' Cc : Brian Elliott; Dave Rees Objet : Notes: PriceMinister and Alibris, August 12, 2010 Hi Everyone, Thank you so much for the informative call, and your patience with the phone system issues. My notes are below - please forward to Laurent as I don't have his email address. I'm hoping you can check the notes for accuracy. We'll be moving forward on the action items, and look forward to talking to you again next week. I'm copying Dave Rees, my project management lead, as he will be assisting on the program. Best regards, Pam ============================================================================ Notes: PriceMinister and Alibris, August 12, 2010 Attendees: Jeremy Pallot, Gael Seguillon, Laurent, Brian Elliott, Pam Nice ============================================================================ Opportunity: ¿ Alibris would like to list and sell its seller inventory on PriceMinister's UK, FR, and ES sites. ¿ Alibris will pass inventory and orders via data replication, as we do on Half, Ebay, and Buy.com today. ¿ PriceMinister's current sales volume is 4m books/year but they're growing. ¿ They expect we could sell 50k-60k orders per month on their properties. ¿ Rakuten is funding additional staffing in UK and ES so sales are expected to increase on those sites quickly. Inventory: ¿ PriceMinister supports several inventory management processes: o Upload, for all items that are already in PriceMinister's catalog (their catalog is also referred to as "standard reference"). o Catalog item creation process. o Adds. o Deletes. o Skinny update, SKU+price change only: does not exist today but PriceMinister will build it for Alibris. o Reconciliation file creation: weekly, currently manual but will automate - this will be functional in one month. ¿ Inventory files: o PriceMinister doesn't enforce limits on the number of listings, but there are file size constraints. o Max recommended size is about .5m items which can take 10 hours to process. o A file with 1.2m lines can take up to 24 hours to process. o Processing for small files for adds, deletes, updates is very fast. o They do not prioritize processing based on file size; it's simply first-in-first-out. o Yes, PriceMinister systems will let us list non-ISBN items, via the Catalog item creation process. Requires unique Alibris SKU. o Yes, we can list multiple copies of a single ISBN, even if they are in the same condition, within a single account, as long as SKU is unique. o Different currencies: Alibris will create separate pricing columns for each currency, all in a single inventory listing file. o Structuring the accounts on PriceMinister: ¿ Alibris can support the following inventory management configurations: o Multiple accounts containing many sellers. o "Vanity" accounts where Alibris manages seller accounts for them. o A combination of the above. ¿ Alibris will probably want to have UK/EU sellers in separate accounts so that the ship times can be faster for those sellers. Orders: ¿ Each account will have a dedicated server. Orders will appear in a folder "Purchase". ¿ PriceMinister must receive order confirmation back within 48 hours (2 business days). ¿ PriceMinister auto-cancels the order after 3 days. ¿ PriceMinister supports customer cancels. Alibris does not support these - they will have to be handled as refunds. Shipping: ¿ UK price must include the shipping uplift as they require free shipping in the UK. For FR and ES, shipping costs are set by Alibris. ¿ Ship-time commitments are set by Alibris in the storefronts. ¿ Ship time from Alibris' US sellers to Europe can be 45 days due to a two-leg process with consolidation. This is OK as long as we set this expectation with the customer in our Storefront. ¿ While PriceMinister supports multiple shipping types, Alibris need only support standard shipping. ¿ Alibris will probably want to have UK/EU sellers in separate accounts so that the ship times can be faster for those sellers. Returns and refunds: ¿ PriceMinister absorbs most returns, including cases where the item was not as expected. ¿ The return instructions will tell the customer to return the item to a PriceMinister address. ¿ PriceMinister pays Alibris, then re-sells the items themselves. ¿ In cases where the customer says they never received the item, PriceMinister sends a standardized email to Alibris. Alibris must respond in 72 hours. The FR and ES emails are translated. ¿ PriceMinister supports customer cancels. Alibris does not support these - they will have to be handled as refunds. Payment: ¿ Payment occurs every 10 days (3x/month), on the 1st, 10th, and 20th day, if the sale is "confirmed" (if the customer left feedback on the sale). ¿ If the customer hasn't left feedback on the sale, Alibris will be paid on the 20th of the following month. The average payment delay is 11 days. ¿ There are no currency concerns surrounding payment, because Alibris sets the price and does the currency conversion in the inventory listing files. ¿ Each site will pay Alibris with a separate bank transfer. ACTIONS and NEXT STEPS: ¿ ACTION: PriceMinister to estimate catalog file size to Alibris. Pam to set up FTP. PriceMinister to provide Alibris with Google Feed for catalog. ¿ ACTION: PriceMinister to make recommendation to Alibris on the optimal account configuration: o Number of accounts. o Max # of listings per account. o Max and recommended file sizes for upload, adds, deletes, updates. ¿ ACTION: PriceMinister to send a shipping file with standard shipping prices, methods, and times. ¿ ACTION: Pam to set up test account at PriceMinister. Jeremy will be the primary account manager contact with Laurent supporting. Note: we may use standard seller agreement, or, if necessary, request a custom contract. ¿ ACTION: Pam to arrange follow up meeting for next Thursday, 7PM Paris time, 30 mins so we can see how things are progressing. |
[CAT-3471] Liste des Tracking de la plateforme Zanox Création: 21/janv./11 11:28 Mise à jour: 25/janv./11 09:39 Résolue: 25/janv./11 09:39 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Non Import |
| Composants: | Outils internes / Rapport |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Remigiusz Woronkiewicz | Attribution: | Rocio Perez-Garcia |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Classif CAT: | Affiliation |
| Description |
|
Bonjour,
Pour faire un état des lieux de nos trackings chez Zanox j'aurais besoin de toute la liste des codes de tracking qui remontent bien chez nous pour les 2 groupes de Trancking : Zanoxx et Zanoxx-Cashbacker (1 variable "VA" en plus dans le tag). En effet, j'ai besoin de savoir si les codes rentrés dans le Back-Office remontent bien en prod et dans BI, et ceci pour éviter toute perte de tracking. Rocio avait déjà fait cet extract pour Effiliation donc elle devrait être en mesure de le faire pour Zanox. A votre disposition pour toute question. Merci d'avance ! Rémi |
| Commentaires |
| Commentaire de Rocio Perez-Garcia [ 24/janv./11 14:44 ] |
|
Salut, voici la liste de trackings selon le type de tag:
- Zanox first buy, buy et 1a MeV: 1544040,1748140,1748141,1748042,2173340,2173341,2173342,1879141,2227466,2227467,2227468,2227469,2227470,2227471,2227472,2227473,2227474,2227475,2227476,2227477,2227478,2227479,2237151,2237152,2237153,2237154,2237155,2237156,2237157,2284845,2284846,2284847,2284848,2284849,2284340,2300345,2300346,2300347,2300348,2300349,2318940,2318941,2318942,2318943,2318944,2337957,2337958,2337959,2337960,2337961,2337962,2337963,2337964,2337965,2337966,2337967,2337968,2337969,2337970,2337971,2337972,2337973,2337974,2337975,2337976 - Zanoxx_cashbackers_Buy: 2318940,2318941,2318942,2318943,2318944 - Zanoxx_oldcashback_buy: 2227469,2227477 |
| Commentaire de Remigiusz Woronkiewicz [ 24/janv./11 14:49 ] |
|
Salut Rocio,
Merci pour ton aide. Bonne journée! Rémi |
[APP-32585] Marquer les messages reçus par "WS Post-vente" Création: 25/janv./11 18:01 Mise à jour: 25/janv./11 18:01 |
|
| Etat: | Ouvert |
| Projet: | Application PriceMinister |
| Composants: | Back-Office, Mails |
| Affecte la/les version(s): | 86.0.0 (TX-R) |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Habib-Sylvain Gourguet | Attribution: | Dispatcher (Pôle TX) |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Projets PM: | WS GetToDoSeller |
| Description |
|
En BO, dans les pages à partir desquelles il est possible de
consulter les messages reçus (fiches user, article, panier...),
permettre de distinguer un message reçu via WS d'un message reçu via
formulaire classique en FO.
Version classe : rajouter un picto à côté des titres des messages sur ces différentes fiches. Version du pauvre : ajouter une ligne dans la popup de visualisation du message et écrire "... (via Web Service)". Marquer les messages reçus via WS permettrait peut-être aussi de récupérer l'info dans BI pour plus facilement (et mieux) analyser les résultats du projet "WS Post-vente". |
[APP-23422] KPI recyclage Création: 02/déc./08 09:41 Mise à jour: 01/sept./09 14:27 |
|
| Etat: | Ouvert |
| Projet: | Application PriceMinister |
| Composants: | Annonces |
| Affecte la/les version(s): | 35.0.1.2, 52.0.0 (CTN-M) |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Thomas Beylot | Attribution: | Dispatcher (Pôle CTN) |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Site: | Prod |
| Projets PM: | *** RESERVE *** |
| WishList: | Marketing |
| WishList - Complexité: | H |
| Classif FONC: | webanalytics |
| Description |
|
Bonjour, Nous souhaiterions pouvoir suivre le nombre d'annonces provenant du recyclage. Du coup il faudrait poser un flag de sorte à ce que nous puissions sortir l'info notamment grâce à BI. En effet, nous allons mettre en place une action crm invitant les acheteurs à mettre en vente les produits listés dans leur listing "revendez vos achats". Ce chiffre nous permettrait de savoir si oui ou non elle a un impact pour envisager de communiquer de façon plus large sur la fonctionnalité. merci, Thomas. |
| Commentaires |
| Commentaire de Swan Desportes [ 03/déc./08 11:29 ] |
| Il s'agit d'une modification de base de données dans le cadre de la mise en vente --> pôle CAT |
| Commentaire de Benoît Bourdon [ 05/août/09 14:52 ] |
|
... désolé de te le renvoyer :-) il me semble que recyclage fait parti des transfo pour le nouveau plan de marquage xiti. --> Jira à fermer à la sortie de la CTN-M ? (par ailleurs ça me semble plus propre de faire ça via un outil de webanalytics plutôt que d'ajouter une info en base sur les annonces ...) |
| Commentaire de Swan Desportes [ 01/sept./09 14:27 ] |
| A traiter après la mise en prod de la V52 |
[APP-21944] [cob] Arrêt du cobranding ACF Création: 02/sept./08 09:58 Mise à jour: 21/janv./09 11:44 Résolue: 12/déc./08 10:07 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Cobrandings |
| Affecte la/les version(s): | 27.0.1 |
| Version(s) corrigée(s): | 39.0.0 (CTN-I) |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Ghislain Gridel | Attribution: | Dispatcher (Pôle CTN) |
| Résolution: | Doublon | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Site: | Prod | ||||||||
| Projets PM: | *** RESERVE *** | ||||||||
| WishList: | Marketing | ||||||||
| WishList - Complexité: | L | ||||||||
| Classif FONC: | cobranding | ||||||||
| Description |
|
Bonjour, ACF souhaite arrêter notre partenariat. Il a pris fin offciellement le 31/08/08. Pouvons-nous activer la procédure de débranchage du cobranding ? 1 / Faire rediriger http://www.radindesbois.com/ vers PM (Exploit) 2 / Arrêter les rapports BI hebdo et mensuel (Décisionnel) 3 / Envoyer un email à tous les comptes pour leur dire qu'ils peuvent continuer à acheter sur PM (Marketing) Ai-je oublié quelque chose ? Ghislain |
| Commentaires |
| Commentaire de Alexandre Garnier [ 12/déc./08 10:07 ] |
|
|
[BIN-476] [Sales/ES] : Rapport hebdo Volume d'affaire comptes dvdlegacy sur l'Espagne Création: 21/août/08 16:47 Mise à jour: 01/oct./08 10:34 Résolue: 22/août/08 10:08 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Sales |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Gaël Seguillon | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ESP - Espagne
|
| Description |
|
J'aurai besoin d'avoir un rapport BI, si possible accessible
depuis mon dossier sur ur sales mes favoris/Gael qui présenterait
chaque semaine, le volume d'affaire des 3 comptes de dvd legacy sur le
site espagnol les logins concernés et les ID vendeurs sont les suivantes legacybooks (10979245) dvdlegacycd (10873093) dvdlegacy_es (10873092) les données dont j'aurai besoin sont un rapport hebdo détaillant pour une semaine l'ensemble des chiffres suivants pour les 3 pseudos de ce pro volume d'affaire (Captured gross merchandise sold) - commission price fixe (captured fix commission) - commission price variable (captured variable commission) merci Gael |
| Commentaires |
| Commentaire de Cyril Tanneau [ 21/août/08 18:48 ] |
|
Bonjour, Nous avons vu ensemble la création du rapport. En attente des résultats de la planification... Merci, Cyril |
| Commentaire de Cyril Tanneau [ 22/août/08 10:08 ] |
|
Bonjour, Tout a l'air de bien fonctionner, le rapport a été correctement généré et envoyé. Gaël, peux-tu vérifier que le rapport est bien envoyé Lundi comme nous l'avons programmé, et clôturer le JIRA si tout est OK. Merci, Cyril |
| Commentaire de Agathe Remy [ 04/sept./08 14:35 ] |
|
Bonjour Gaël, Peux-tu valider la demande afin que nous la clôturions? Merci. Agathe |
[BIN-657] [Cobranding] : Actualisation du rapport "PriceMinister - Authorized co-branding type LRO" avec l'information "Refused negociated GMS" Création: 25/févr./10 18:21 Mise à jour: 25/mars/10 17:20 Résolue: 25/mars/10 17:20 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Jonathan Gorges | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Comme vu ensemble, nous voulons actualiser le reporting BI "PriceMinister - Authorized co-branding type LRO" se situant dans le dossier public "Cobranding". Sauf erreur de ma part, la colonne appelée "VA Buyer" doit aujour'hui inclure les négociations refusées. Pourriez-vous dans un premier temps vérifier si cela est bien vrai svp ? Aussi, nous voudrions inclure sur la droite de ce rapport, en dernière colonne (pour ne pas perturber nos tableaux croisés dynamiques") une colonne "Refused negociated GMS". Je reste à votre disposition pour toute information complémentaire. PS : Dalila, les rapports de COB présents à la fois dans le dossier privé d'Aurélie et dans le dossier public COB sont bien les mêmes. Jonathan |
| Commentaires |
| Commentaire de Cyril Tanneau [ 25/mars/10 17:20 ] |
|
Jonathan, comme vu ensemble à l'instant, le rapport PriceMinister - Authorized co-branding type LRO permet de ressortir les VA acheteurs, VA vendeurs et VA Acheteurs/vendeurs cobrandés. Ces montants sont capturés, ils ne comprennent donc pas de négo refusées, qui par définition ne sont pas capturées. Je ferme donc le JIRA, Merci, Cyril |
[BIN-430] [SBP] : Prise en compte des suppressions de colonnes Création: 15/avr./08 16:08 Mise à jour: 17/août/09 15:41 Résolue: 10/juin/08 10:08 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Bug & Improvement |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | Julien Girardet |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Prendre en compte les suppressions de colonnes suivantes en
même temps que les impacts de la centralisation PMV (objectifs MEP
mi-mai): ALTER TABLE prd_configuration DROP COLUMN is_cpl_mono_advert; ALTER TABLE image DROP COLUMN is_migrated; ALTER TABLE prd_attribute DROP COLUMN is_inherited ; ALTER TABLE compensation DROP COLUMN old_ubk_iban_control; ALTER TABLE usr_bank_account DROP COLUMN old_iban_control; Les éléments possiblement impactés sont : - alimentation BI (ODS/DTM, France/Espagne) - rapports titan - flux partenaires (1000Mercis) Merci. Agathe |
[BIN-572] Rapport vendeurs catégorie mode Création: 30/mars/09 18:36 Mise à jour: 30/avr./09 16:18 Résolue: 30/avr./09 16:18 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Charlotte Fachan | Attribution: | Agathe Remy |
| Résolution: | Invalid | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Salut à tous, nous souhaitons informer nos vendeurs de la mise en place du nouveau formulaire mode et accessoires. Les objectifs du mailing sont : o augmenter le nombre de mev Mode abouties o augmenter la qualité des annonces enregistrées o augmenter le nombre de vente dans la catégorie mode. J'aurais aimé un comptage pour affiner les cibles de notre emailing. Je souhaiterias connaître le nombre vendeurs qui ont fait une mev dans la catégorie mode (et accessoires de mode) avant le 13/11/08 et qui aujourd'hui n'ont toujours pas vendu leur article. j'ai commencé un rapport que j'ai enregistré dans mon public mais je bug un peu. Dans l'idéal j'aurais aimé aussi connaître le nombre de vendeurs qui ont fait une mev « non aboutie ». A t - on cette info dans BI ? Merci Charlotte |
| Commentaires |
| Commentaire de Agathe Remy [ 28/avr./09 16:07 ] |
|
Bonjour Charlotte, La News Vente annonçant la mise en place du nouveau formulaire mode et accessoires ayant été envoyée le 17/04, cette demande est-elle obsolète? Merci. Agathe |
| Commentaire de Charlotte Fachan [ 30/avr./09 16:10 ] |
|
effectivement ;-) merci. Charlotte |
[EXP-4892] création d'alias pour le back office Création: 16/juil./09 11:04 Mise à jour: 16/juil./09 17:29 Résolue: 16/juil./09 17:29 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Steven Harel | Attribution: | Stéphane Eccli |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
| Commentaires |
| Commentaire de Stéphane Eccli [ 16/juil./09 16:24 ] |
|
les adresses sont créées sur le serveur. est ce qu'elles seront utilisées depuis l'extérieur ou juste en interne ? |
| Commentaire de Steven Harel [ 16/juil./09 16:44 ] |
|
juste en interne merci ! |
| Commentaire de Stéphane Eccli [ 16/juil./09 17:29 ] |
| done |
[BIN-701] Création d'un univers "ITEM EVENT" Création: 29/déc./10 19:07 Mise à jour: 17/févr./11 14:51 Résolue: 16/févr./11 16:31 |
|
| Etat: | Résolu |
| Projet: | Business Intelligence |
| Composants: | BackOffice |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Habib-Sylvain Gourguet | Attribution: | Valéria Gusa |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Description |
|
L'équipe TX a récemment effectué (dans le cadre du CoSAV) des développements majeurs à l'attention du Back Office :
- ajout de l'identifiant BO dans plusieurs "événements article" (notamment ceux liés au processus de réclamation), - mise en place du gestionnaire de commandes, avec là aussi de nouveaux "événements article" (ex. : annulation de la vente par le vendeur). Le Back Office souhaiterait s'appuyer sur BI pour mieux analyser le comportement de certains utilisateurs d'une part (pour de futurs développements, meilleure détection de la fraude...), et l'évolution de l'activité du pôle SAV d'autre part (actions effectuées sur les articles, nombre de traitements réalisés sur une réclamation...). Un univers "ITEM EVENT" permettra une meilleure appréciation de ces données, là où des univers existants tels que "ITEM" ou "MESSAGE" (déjà utilisés dans certains rapports) montrent leurs limites. |
| Commentaires |
| Commentaire de Habib-Sylvain Gourguet [ 29/déc./10 19:08 ] |
| Steven en copie pour info. |
| Commentaire de Habib-Sylvain Gourguet [ 11/janv./11 10:50 ] |
| Emeric et Thomas en copie pour info. |
| Commentaire de Valéria Gusa [ 16/févr./11 16:31 ] |
|
Bonjour Habib,
L'univers ITEM EVENT vient d'être livré sur les trois pays FR/ES/UK. Merci Valeria |
| Commentaire de Habib-Sylvain Gourguet [ 16/févr./11 19:22 ] |
|
Génial, merci à toi et à Julien.
Quelle rapidité ! :-) Je n'hésiterai pas à revenir vers vous pour d'éventuelles remarques. |
| Commentaire de Steven Harel [ 17/févr./11 14:45 ] |
|
ouais ça avance bien, c'est cool, merci
On se voit pour voir tout ce qu'on peut faire avec ça |
| Commentaire de Valéria Gusa [ 17/févr./11 14:51 ] |
|
Je refais juste un petit point pour donner un peu plus de
précision sur les possibilités liées au nom de l'opérateur.
Nous avons mis a disposition deux objets : _ La dimension "Iten event operator name" qui permet d'afficher le nom de l'opérateur BO qui a traité l'événement. _ Le filtre " Select item event operator" qui permet de sélectionner tous les évènements traités par un opérateur en particulier. Ce filtre n'est pas sensible à la casse mais est sensible aux accents. Merci Valeria |
[APP-17272] Abonnements Création: 25/juil./07 15:21 Mise à jour: 17/août/07 11:11 Résolue: 16/août/07 14:28 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 15.0.1, 15.0.2, 15.0.3, 15.1.0 |
| Version(s) corrigée(s): | 16.0.0 |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Agathe Remy | Attribution: | Patrick Pereira |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Bug_subscription_events_20070726.xls
|
| Pays: |
ALL - Tous
|
| Projets PM archivés: | Maintenance 16.x.x |
| Description |
|
Bonjour, En mettant en place le reporting sur les abonnements, j'ai constaté certaines incohérences dans les données: -Un évènement " Abonnement aux ventes évènementielles proposées par 24h" avec la description "Migration refonte abonnements ( -Un script post-deploy a tourné tous les jours depuis le 12/07/2007, créant des évènements avec une date de création antérieure à leur date réelle de création et donc créant des incohérences entre le BI et les données du site. Nous avons désactivé sa programmation avec Patrice. Je suis à votre dispo si vous avez besoin de plus de précisions. Agathe |
| Commentaires |
| Commentaire de Arnaud Forgues [ 26/juil./07 10:23 ] |
| Agathe, pourrais-tu me donner des exemples de comptes ? Merci |
| Commentaire de Agathe Remy [ 26/juil./07 11:30 ] |
|
Tu trouveras ci-joint la liste exhaustive des évènements
"24H" créés avec une date de création antérieure à leur date réelle de
création et comprise entre le 13/07/2007 et aujourd'hui. En revanche, sur la journée du 12/07/2007 je ne sais pas débrouiller le juste du faux... Agathe |
| Commentaire de Arnaud Forgues [ 26/juil./07 18:19 ] |
|
Merci ! Pour te rassurer, je te confirme qu'il n'y a que des abonnements de type 24h qui sont concernés par ce pb. |
| Commentaire de Arnaud Forgues [ 27/juil./07 10:30 ] |
|
On a donc a priori 35470 évenement à supprimer. Ils le seront en PROD grâce au script suivant : V:\Database\V16_0_0\integ\01_PREPARE\ONLINE\V16_0_0_APP_17272_FRA_01_usr_event_delete_24h.sql Patrick, je te transmet donc le JIRA pour que tu passes ce script en PRE DEPLOY de la V16 dès que possible Merci |
| Commentaire de Agathe Remy [ 27/juil./07 18:43 ] |
|
Un second problème est apparu : il semble qu'il y ait de
très nombreux doublons sur l'évènement 140 et la journée du 12/12/2007. Voici la requête que j'ai effectuée pour rechercher ces doublons : SELECT user_account_id, creation_date, mail_subscription_id, COUNT(DISTINCT usr_event_id) FROM usr_event WHERE use_type_code=600 AND description LIKE '% GROUP BY user_account_id, creation_date, mail_subscription_id HAVING COUNT(DISTINCT usr_event_id)>1 ; Le résultat se trouve dans le fichier : V:\Reporting\BusinessIntelligence\Evolutions\Subscription\doulons_listing.csv (plus de 2 000 000 d'enregistrements). J'ai vérifié, et il n'y a pas de doublon sur USR_SUBSCRIPTION. Agathe |
| Commentaire de Patrick Pereira [ 31/juil./07 12:49 ] |
|
En effet. Il y a un problème. J'ai l'impression que le 12/7 on a lancé 2 fois en même temps le script d'insertion. Je vais faire un script correctif. |
| Commentaire de Patrick Pereira [ 16/août/07 14:28 ] |
| C'est corrigé. |
Contrat Bris&Vol [Metatache]
(APP-16575)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 14.2.0 |
| Version(s) corrigée(s): | 17.0.0 |
| Type: | Sub-bug | Priorité: | Mineur |
| Rapporteur: | Richard Dubois | Attribution: | Swan Desportes |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
noter_le_vendeur.JPG
|
| Pays: |
ALL - Tous
|
| Site: | Prod |
| Projets PM archivés: | Contrat "Bris et Vol" |
| Description |
|
Actuellement pour effectuer une réclamation, au niveau de la
page « Notez vos vendeurs », une proportion non négligeable d'acheteurs
utilise le lien « >> Noter votre vendeur » au lieu du lien «
>> Demander de l'aide », sans se rendre compte qu'il s'agit de 2
liens distincts car ils sont très proches l'un de l'autre. Ainsi,
l'acheteur pense que sa demande est prise en compte par le SAV et
qu'elle sera traitée. Or, le SAV ne contrôle / surveille pas les
messages de notation et ne peux donc pas répondre aux réclamations
effectuées par ce biais, ce qui génère de l'insatisfaction. La mise en place des garanties sur PriceMinister risque d'augmenter ce phénomène. Il semble donc pertinent de traiter ce problème en préliminaire du chantier garantie. Sur la page « notez vos vendeur » sauter une ligne et mettre un espace significatif entre les liens « >> Noter votre vendeur » et « >> Demander de l'aide ». |
| Commentaires |
| Commentaire de Sébastien Aubert [ 17/juil./07 18:20 ] |
|
Ce problème est traité dans le projet reserve "transaction notée/ produit non reçu" jira |
| Commentaire de Alexandre Garnier [ 26/sept./07 15:34 ] |
| TNNR |
| Commentaire de Sébastien Aubert [ 08/oct./07 15:16 ] |
| ok traité avec projet TNNR |
[APP-24551] [Liens sponsos Keyade] Nouveaux tags Keyade/Xiti Création: 09/mars/09 18:00 Mise à jour: 11/mars/09 16:27 Résolue: 11/mars/09 10:33 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 42.0.0 (CTN-J) |
| Version(s) corrigée(s): | 42.0.1 |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Damien Dorizy | Attribution: | Damien Dorizy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM: | *** RESERVE *** |
| Description |
|
Afin de pousser plus loin les tests pour comprendre pourquoi
20% des tags Keyade ne sont pas remontés, on souhaite mettre en place
ce qui suit : - Pour chaque tag Keyade posé, on pose un tag Xiti (dans la fonction JS pour avoir des conditions similaires) - Les tags "tests" Keyade (dtool.keyade.com) sont posés avec la méthode javascript "document.write", à la différence des tags "normaux" (k.keyade.com) qui utilisent toujours la méthode new Image(), afin de pouvoir évaluer un éventuel problème à ce niveau là. - Si le cookie "slid" n'est pas trouvé (ce qui ne devrait pas être le cas), on pose un tag Xiti. Cela permettra de confondre les informations Xiti avec celles du BI et de Keyade, et peut-être de déterminer la cause du problème. |
| Commentaires |
| Commentaire de Damien Dorizy [ 09/mars/09 18:04 ] |
|
cms1 + cms3 /promotions/Promotions/FR/Liens sponso/Keyade/Panier - 3 tags - test /promotions/Promotions/FR/Liens sponso/Keyade/Panier - 3 tags /promotions/Resource/pr.js merci |
| Commentaire de Christophe Garcia [ 09/mars/09 18:43 ] |
|
J'espère que vous avez testé ce truc à mort. Cette évolution n'a fait l'objet d'AUCUNE DISCUSSION avec l'équipe d'INTEG : elle est livrée à 18H le jour du bouclage de la version. |
| Commentaire de Damien Dorizy [ 10/mars/09 09:56 ] |
| Ok pour 42.0.1 |
[APP-17315] probleme sur les montants capturés operation sur 4 paniers Création: 26/juil./07 17:42 Mise à jour: 08/août/07 18:59 Résolue: 06/août/07 17:44 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Base de données, Panier |
| Affecte la/les version(s): | 15.1.2 |
| Version(s) corrigée(s): | 15.1.2 |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Romain Czornomaz | Attribution: | Patrick Pereira |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Site: | Prod | ||||||||
| Projets PM archivés: | Maintenance 15.x.x | ||||||||
| Description |
|
Bonjour, il y a en production 4 paniers dont les montants operation de la table OPERATION sont bien passés en finalisé mais les montants capturés operation (CAPTURE_OPERATION_AMOUNT) dans la table PURCHASE n'ont pas été mis à jour. Paniers impactés: 34145670 --> montant: 8.75 34156881 --> montant: 14.33 34157335 --> montant: 20.2 34500782 --> montant: 250.3 Pouvez vous regarder pour corriger le probleme? NB: En cas d'UPDATE sur la table PURCHASE, pensez à mettre à jour la CHANGE_DATE afin que les modifications soient prise en compte dans l'alimentation BI. |
| Commentaires |
| Commentaire de Romain Czornomaz [ 27/juil./07 14:49 ] |
|
Genevieve, Voici le numéro de la demande que tu avais traité auparavant. Bonne journée, Romain |
| Commentaire de Geneviève Beaujard [ 31/juil./07 16:03 ] |
| Peux tu passer le script APP17315_FRA_update_purchase.sql qui se trouve dans V15_1_1 |
| Commentaire de Patrick Pereira [ 06/août/07 17:44 ] |
| C'est fait. |
[APP-20690] Impossible de refuser une opération de crédit BO depuis le détail operation Création: 29/mai/08 11:04 Mise à jour: 30/mai/08 14:56 Résolue: 30/mai/08 10:31 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 22.1.1 |
| Version(s) corrigée(s): | 22.1.2 |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Arnaud Forgues | Attribution: | Arnaud Forgues |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Classif1: | PMV |
| Classif2: | operation |
| Projets PM archivés: | Paiement - Automatisation bordereaux |
| Description |
|
Depuis le déploiement de la TX-A, il est impossible
d'éffectuer un refus sur un crédit BO, dans le cas où le SAV a utilisé
la macro de remboursement PMV à tort. Du coup, ils sont obligé de
finalisé les opérations puis de créer une opération de débit BO du
montant opposé. Cela n'est pas du tout pratique et on n'a aucun lien
entre ces 2 opérations si on souhaite les rapprocher ultérieurement dans
des rapports BI. Du coup, il faut autoriser le refus d'une opération dans l'état APPROVED dans le cas ou il s'agit d'un crédit BO. A tester donc uniquement le refus d'une opération en BO : c'est le seul impact possible de la correction |
| Commentaires |
| Commentaire de Emeric Teil [ 29/mai/08 13:30 ] |
| Quid des Crédit Bo Récup chèque et des débits BO ??? |
| Commentaire de Arnaud Forgues [ 30/mai/08 10:31 ] |
| oK |
[APP-29031] Tirage au sort du gagnant jeu concours widget de mars Création: 06/avr./10 11:11 Mise à jour: 25/juin/10 11:11 Résolue: 18/juin/10 17:05 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 72.0.0 (VEN-C) |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Audrey Angleys | Attribution: | Fabrice Feugas |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM: | *** RESERVE *** |
| WishList: | Marketing |
| Classif1: | WIDGET |
| Classif FONC: | widget |
| Description |
|
Hello, La news d'annonce de fin du jeu concours widgets est supposée partir ce samedi 10/04. (version perdants via MM / version gagnant grâce au nouveau système d'attribution de coupon avec mail via le Back Office). Il faudrait donc sortir le fichier des personnes ayant participé => Fabrice/Renaud/BI? Puis tirer au sort un gagnant => serait-il possible de créer un système dans le BO comme pour le jeu avis? Sinon, pouvez-vous transmettre le fichier des inscrits à Eric pour le tirage au sort comme la dernière fois? Fabrice, je t'attribue le JIRA, pourras-tu me tenir au courant des démarches à suivre/personnes à qui m'adresser si besoin? Merci beaucoup! Audrey |
| Commentaires |
| Commentaire de Fabrice Feugas [ 18/juin/10 17:01 ] |
| Oula, pas déjà réglé depuis le temps ? |
[APP-28871] Liste participants jeu concours avis Création: 24/mars/10 15:27 Mise à jour: 01/oct./10 11:43 Résolue: 13/août/10 16:17 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 65.0.1 |
| Version(s) corrigée(s): | 78.0.0 (CTN-TU) |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Carole Visser | Attribution: | Renaud Dierickx |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Projets PM: | *** CHASSE *** | ||||||||
| Classif FONC: | avis | ||||||||
| Description |
|
Bonjour, Dans la cadre du jeu concours permanent avis, un gagnant est tiré au sort chaque mois. On lui attribue donc son coupon et il est contacté directement par le BO. Un mail est également envoyé par 1000Mercis à l'ensemble des autres participants pour leur annoncer qu'ils n'ont pas gagné ce mois ci et les inviter à retenter leur chance le mois prochain. Les données d'inscription au jeu concours et les points accumulés ne sont transmis à 1000Mercis. Il faut donc générer la cible chaque mois et leur envoyer. Pour le moment, l'équipe BI s'occupe de la requête mais il faudrait à terme pourvoir obtenir la liste des participants au jeu concours avis du mois M-1 au moment du tirage au sort depuis le BO. Merci d'avance, Carole |
| Commentaires |
| Commentaire de Fabrice Feugas [ 25/mars/10 12:00 ] |
|
La liste doit aller du début du mois M-1 jusqu'au moment de
l'extract, en sachant que le tirage au sort et l'extract devront être
fait quasiment en même temps. Agathe, peux-tu nous communiquer la requête que vous utilisez ? Merci. |
| Commentaire de Agathe Remy [ 25/mars/10 12:11 ] |
|
Voici le JIRA dans lequel vous trouverez la requête d'extraction. Celle-ci se base sur vos critères de tirage au sort vu avec Renaud. Agathe |
| Commentaire de Renaud Dierickx [ 13/août/10 16:17 ] |
|
Sur la branche CTN. Chasse comptant pour 2 : http://perrier:8090/dev/pole/ctn/revision/25077 [CAJ2010Q3CTN] |
[IMP-8128] WEBSERVICES : MOBILINNOV : explications Création: 22/févr./11 11:54 Mise à jour: 22/févr./11 11:54 |
|
| Etat: | Ouvert |
| Projet: | Paramétrage - Import |
| Composants: | Support entrant |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Laurent Payot | Attribution: | Laurent Payot |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Login: | MOBILINNOV |
| Séparateur: | N/A |
| Type de traitement: |
N/A
|
| Description |
|
De : Yohan Azoulay [mailto:yazoulay@ihtconsulting.com]
Envoyé : vendredi 18 février 2011 10:21 À : 'Support Pro' Objet : RE: Soumission Catalogue Priceminister par API Bonjour, Merci pour votre insertion rapide. J'ai néanmoins une question. Est il possible de transférer les commandes PRICEMINISTER directement dans notre BACK OFFICE par le biais d'une API par exemple afin d'avoir une réactivité plus importante quant à la gestion des commandes. Nous souhaiterions pouvoir visualiser la commande / Valider la commande / envoyer le numéro de suivi au client directement depuis notre Back Office. Merci pour votre retour. Cordialement, Yohan Azoulay - Directeur informatique www.portable-accessoire.com 01.77.35.78.34 |
[BIN-532] Tronquage de données rapport ur sales à j-3 Création: 19/déc./08 17:42 Mise à jour: 24/déc./08 14:11 Résolue: 24/déc./08 14:11 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Sales |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Dorian Porta Delsol | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
UR Sales --> Favoris --> Dorian --> Suivi vendeur (courte période) Il y a donc un problème sur les chiffres des dernières journées qui semblent être tronqués (à partir de J-3) : exemple sur le compte Espace3games du 20/10/2008 au 18/12/2008 : nb de vente par jour (valeur back office) : 05/12/2008 8 06/12/2008 6 07/12/2008 11 08/12/2008 7 09/12/2008 14 10/12/2008 18 11/12/2008 15 12/12/2008 13 13/12/2008 27 14/12/2008 16 15/12/2008 15 16/12/2008 10 17/12/2008 20 18/12/2008 36 nb de vente par jour (rapport BI) : 05/12/2008 8 06/12/2008 6 07/12/2008 11 08/12/2008 7 09/12/2008 14 10/12/2008 18 11/12/2008 15 12/12/2008 13 13/12/2008 27 14/12/2008 16 15/12/2008 15 16/12/2008 10 17/12/2008 17 18/12/2008 10 Les valeurs sont inexactes pour le 17 et le 18 et aucun soucis sur les autres journées. J'ai exécuté le rapport le 19/12. A votre disposition si besoin est. Merci Dorian |
| Commentaires |
| Commentaire de Dalila Belkebir [ 24/déc./08 14:11 ] |
|
Vu entre Cyril & Dorian : Le rapport se basait sur des statuts "finaux" de paniers . Or ces statuts n'apparaissent pas pour les paniers les + récents. Dalila. |
[BIN-218] evaluation du test coupon vendeur Création: 10/nov./06 12:09 Mise à jour: 14/sept./07 17:31 Résolue: 19/janv./07 18:24 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Alexandra Viravaud | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Hello Agathe, Nous allons bientôt faire un test sur le coupon vendeur. Principe du test : Proposer aux acheteurs qui n'ont pas d'inventaire de découvrir la vente sur PM et leur attribuer un bon d'achat s'ils réalisent une 1ère vente clôturée sur le site. Pour évaluer l'efficacité de cette opération, nous aurons besoin de connaître, pour chacun des mails comportant les coupons de 3,5 7 euros : - le nb de coupons vendeur utilisé - le nb d'acheteurs devenus vendeurs (date de dépôt de 1ère annonce is not empty) - le nb d'acheteurs devenus vendeurs réels (au moins 1 vente cloturée) - le CA généré - le nb de paniers ... Je voudrais voir avec toi comment nous allons receuillir le résultat de cette opération. Est-ce qu'un simple tracking et la mise en place d'un rapport sur BI suffisent ? On s'en repale de vive voie si besoin. alexandra |
[BIN-452] [Sales] : Rapport de pricing pour les vendeurs pros Création: 28/mai/08 19:43 Mise à jour: 08/juil./08 10:53 Résolue: 03/juin/08 17:07 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Sales |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Nouvelle fonctionnalité | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | Florian Ambrosi |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Contexte : début de mise en place de services de reporting
pour les vendeurs professionnels afin de définir à terme des offres de
souscription à ces services qui pourraient etre payantes. Objectif : fournir aux commerciaux un rapport permettant d'identifier & d'exporter les annonces d'un vendeur professionnel dont le prix de vente est sensiblement supérieur au meilleur prix neuf des annonces de la même fiche produit. On parle bien du meilleur prix neuf, ce qui implique une limitation du scope de comparaison aux vendeurs PRO. L'idée est de reprendre le rapport d'export de stock et de le faire évoluer afin de ne restituer que les annonces dont le prix de vente est supérieur de x% au meilleur prix neuf du même produit. Le seuil d'écart x serait à saisir dans une invite lors du rafraîchissement du rapport. D'autre part, les annonces du rapport seraient triées par écart décroissant. Avant de faire évoluer le rapport, il s'agit de vérifier que l'information "meilleur prix neuf" est correctement alimentée dans BI et que cette information est fiable. |
| Commentaires |
| Commentaire de Justin Ziegler [ 30/mai/08 12:41 ] |
| J'ai modifié un peu la description. |
| Commentaire de Justin Ziegler [ 30/mai/08 14:24 ] |
| nb pour Gael et Benjamin : je pense qu'il sera interessant d'utiliser ceci avec en utilisant la fonction d'abonement par mail à un rapport hebdo par ex. |
| Commentaire de Agathe Remy [ 09/juin/08 17:22 ] |
|
Bonjour, Il est possible qu'un vendeur Pro vendent des produits d'occasion. Dans ce cas, il y a des chances qu'il n'existe pas de meilleur prix neuf sur la fiche produit. Ainsi, peut-on restreindre le périmètre du rapport aux annonces neuves du vendeur pro? Merci de votre retour. Agathe |
| Commentaire de Justin Ziegler [ 09/juin/08 19:29 ] |
| on en parle de vive voix ? |
| Commentaire de Agathe Remy [ 10/juin/08 10:18 ] |
|
Je propose donc de filtrer les annonces neuves et visibles
sur les site (i.e. qui sont actives, ont du stock et ne sont pas
périmées). Dans ce cas là, il existe toujours un meilleur prix neuf sur
la fiche produit. D'autres rapports pourront être envisagés ultérieurement pour exporter les produits d'occasion d'un vendeur pro dont le prix est supérieur au meilleur prix d'occasion. Mais l'information est alors moins pertinente puisqu'un produit d'occasion peut être "Comme neuf", en "Très bon état", en "Bon état", en "Etat correct" ou "Hors service" et nous ne disposons pas de l'information "meilleur prix" à ce niveau de détail aujourd'hui. Autre rapport qui pourrait également envisagé : export des annonces sans stock ou périmées. Agathe |
| Commentaire de Justin Ziegler [ 10/juin/08 10:44 ] |
|
petite précision : il me semble que les annonces HS ne sont pas prises en compte dans le calcul du "meilleur prix d'occasion" |
| Commentaire de Florian Ambrosi [ 10/juin/08 11:36 ] |
|
Le rapport "New product pricing by login" est passé en prod en France et en Espagne dans le dossier "Sales". Florian |
| Commentaire de Benjamin Guerville [ 10/juin/08 18:10 ] |
|
ça à l'air top, Agathe, par rapport à la formation dont tu m'as parlé, je vois ça avec PKR et les autres CDM mercredi et reviens vers toi |
[APP-19587] Affecter les comptes pros à un commercial Création: 13/févr./08 18:06 Mise à jour: 07/déc./09 12:48 Résolue: 07/déc./09 12:48 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 19.0.0 |
| Version(s) corrigée(s): | 22.0.0 |
| Type: | Nouvelle fonctionnalité | Priorité: | Mineur |
| Rapporteur: | Pierre Krings | Attribution: | Validator |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Site: | Prod |
| Projets PM: | *** RESERVE *** |
| Projets PM archivés: | Espace "Commercial" |
| Description |
|
A destination d'Emeric. Projet Light vu avec QdC, a priori bon pour un traitement rapide en mode réserve. Afin de faciliter la vie de l'équipe Commerciale, et d'être moins dépendant de l'outil 4D, l'idée est de renseigner directement dans la base de données le nom du commercial dont dépend chaque compte pro. Charge à l'équipe BI d'incorporer cette info dans les data marts qui conviennent. Benjamin en fera ensuite son affaire. Qques pistes de ce qu'on souhaite : - A priori, utile pour les pros mais c'est peut-être + simple de le prévoir pour tous les types de comptes quitte à ce que ça reste vide - Nouveau champ "Commercial" dans la fenêtre "Droits" - A priori champ libre, charge à benjamin de faire les modifs en cas de doublons dus à des erreurs d'orthographe (Dorian / DOrian) - Remplissage One-shot de l'existant à partir d'un export de 4D - La suite sera gérée manuellement par les cdm |
| Commentaires |
| Commentaire de Arnaud Forgues [ 06/mars/08 15:31 ] |
| un doc de conception est disponible à cette adresse : V:\Projets\reserve_fonc_JIRAs\Affecter_commercial_aux_comptes_pros |
| Commentaire de Emeric Teil [ 13/mars/08 14:29 ] |
| Comme prévu, cette demande est pour Habibata. |
| Commentaire de Emeric Teil [ 14/mars/08 09:26 ] |
|
Pour info, voici ce qui sera implémenté : -> Ancrage : fenêtre des "droits" sur la page User en BO -> Fonctionnalité : une dropdown créée à partir de la liste des Commerciaux insérée dans le BackOffice (il sera donc possible d'ajouter, de supprimer ou de modifier des utilisateurs de type "commerciaux") Voilà :o) |
| Commentaire de Emeric Teil [ 14/mars/08 09:27 ] |
| Dernière précision : cette information ne sera disponible que pour les vendeurs Pros |
| Commentaire de Pierre Krings [ 14/mars/08 10:14 ] |
|
QQUES QUESTIONS/REMARQUES : -> Fonctionnalité : une dropdown créée à partir de la liste des Commerciaux insérée dans le BackOffice (il sera donc possible d'ajouter, de supprimer ou de modifier des utilisateurs de type "commerciaux") : CA VEUT DIRE QU'IL FAUDRA CREER UN BACK OFFICE DE GESTION DES UTILISATEUR COMMERCIAUX ? J'AI L'IMPRESSION QUE C'EST PAS MAL DE BOULOT ET QUE CA RISQUE DE MANQUER DE SOUPLESSE DANS CERTAINS CAS, TOUT CA POUR EVITER QQUES DOUBLONS QUI NE SONT PAS UN GROS PB. Dernière précision : cette information ne sera disponible que pour les vendeurs Pros EST-ON SUR QU'IL N'Y AURA PAS DANS LE FUTUR D'AUTRES UTILISATIONS (SUIVI DE CLIENTS "VIP", FRAUDEURS OU TEMOINS, ETC), QUID DES COMPTES QUI PASSENT DE PART A PRO PUIS PART A NOUVEAU ? JE ME DEMANDE SI CE N'EST PAS PLUS SIMPLE DE LAISSER OUVERT ET DE SURVEILLER DE TEMPS EN TEMPS VIA BUSINESS OBJECT. |
| Commentaire de Habibata Coulibaly [ 21/mars/08 11:35 ] |
| Le projet est livré sur la branche TX_20082702 |
| Commentaire de Emeric Teil [ 15/mai/08 19:35 ] |
| OK en Integ |
[APP-28652] creation_date d'evenement operation (opr_event) antérieur à la creation_date de l'opération Création: 09/mars/10 14:54 Mise à jour: 09/mars/10 14:54 |
|
| Etat: | Ouvert |
| Projet: | Application PriceMinister |
| Composants: | Base de données |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Julien Girardet | Attribution: | Dispatcher (Pôle TX) |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
GBR - Royaume Uni
|
| Site: | Prod |
| Projets PM: | *** A PLANIFIER *** |
| Description |
|
Sur UK, on observe certaines operations créées en BDD après
ses événements (OPR_EVENT.CREATION_DATE < OPERATION.CREATION_DATE) exemple : OPERATION_ID CREATION_DATE OPR_EVENT_ID CREATION_DATE 10241998 15/01/2010 00:00:42 4981174 14/01/2010 23:58:40 10241998 15/01/2010 00:00:42 4981175 14/01/2010 23:58:40 10473996 27/02/2010 00:00:43 4992134 26/02/2010 23:59:21 10473996 27/02/2010 00:00:43 4992135 26/02/2010 23:59:21 Impacts BI : Nous dénormalisons quotidiennement la date de "completion" d'une operation. Or lorsque ce phénomène se produit à cheval sur 2 jours (les événements créées la veille et l'opération créée le lendemain), notre calcul de dénormalisation est éronée. Au final nous constatons des écarts sur les rapports de réconciliation des compensations. Merci. |
[APP-18598] Correction des montants capturés sur 2 paniers sur la base Espagne Création: 20/nov./07 18:21 Mise à jour: 27/nov./07 14:40 Résolue: 27/nov./07 14:26 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Base de données |
| Affecte la/les version(s): | 19.0.0 |
| Version(s) corrigée(s): | 17.2.1 |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Romain Czornomaz | Attribution: | Patrick Pereira |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ESP - Espagne
|
| Site: | Prod |
| Projets PM archivés: | Maintenance 17.x.x |
| Description |
|
Bonjour, En analysant les écarts de la dette vendeur sur la plateforme Espagne, nous nous sommes rendus compte que 2 paniers effectués en Novembre 2006 par fred et Nerya avaient été passé en capture manuelle avec des montants cartes capturés à 0. Or, il y a bien eu des commissions prélevées au niveau Item et les compensations sur les items ont été effectuées. Afin de ne plus avoir d'ecarts sur la dette vendeur, il faudrait mettre à jour le montant carte capturé (capture_card_amount) de la table PURCHASE sur les paniers suiavnts: - PURCHASE_ID= 34285834 , AUTHORIZATION_CARD_AMOUNT= 8 ------> UPDATE DE CAPTURE_CARD_AMOUNT = 8 - PURCHASE_ID= 34285835 , AUTHORIZATION_CARD_AMOUNT= 8 ------> UPDATE DE CAPTURE_CARD_AMOUNT = 8 Arnaud, peux-tu penser à mettre à jour la CHANGE_DATE pour les 2 enregistrements afin que nous puissions prendre en compte les modifs sur le BI. Merci d'avance, Romain |
| Commentaires |
| Commentaire de Arnaud Forgues [ 26/nov./07 19:05 ] |
|
Bon c'est OK ! J'ai fait le script qui va bien et je l'ai passé en INTEG espagne et ca a l'air bon le script est : V:\Database\V19_0_0\integ\V19_0_0_ |
| Commentaire de Christophe Garcia [ 27/nov./07 14:19 ] |
| A toi de jouer |
| Commentaire de Patrick Pereira [ 27/nov./07 14:25 ] |
|
C'est passé en prod. Du coup j'ai renommé et déplacé le script : V18_0_0_ |
[APP-20695] [CoSAV] Messagerie BO - faire en sorte que les messages supprimés restent en répondu dans leur boite d'origine. Création: 29/mai/08 14:52 Mise à jour: 25/nov./09 17:42 Résolue: 04/nov./09 14:58 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Back-Office |
| Affecte la/les version(s): | 22.1.1 |
| Version(s) corrigée(s): | 58.0.0 (TX-K) |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Cedric Favero | Attribution: | Dispatcher (Pôle TX) |
| Résolution: | Aucune correction envisagée | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM: | *** RESERVE *** |
| Classif FONC: | CoSAV |
| Description |
|
Récemment , le BI nous a donné la possibilité de sortir des rapports sur les messages entrants/sortants. Pour nous c'est un outil très important nous permettant de suivre par exemple le nombre de messages reçus dans telle ou telle boite. Pour savoir la boite de réception du message ,on utilise le "incoming context" mais celui-ci ne garde pas obligatoirement sa valeur d'origine. Si on transfère le message dans une autre boite , ce sera la derniere qui sera prise en compte. Pb: pour les traitements SAV , bien souvent , on ne répond pas à proprement parler au message mais on le supprime et on clique sur une macro pour effectuer la traitement et envoyer un mail. Dans ce cas le message passe en état REPONDU et est transféré dans la boite TRASH. Conséquence: les chiffres de nos rapports sont completement erronés car une proportion importante des messages apparait alors dans la boite TRASH. => question: est-il obligatoire qu'un message supprimé soit "transféré" dans la boite TRASH ? Ne pourrait-il simplement passer en l'état REPONDU et rester dans sa boite d'origine? Quelle difference celà ferait-il? |
[IMP-6928] FOIRDISCOUNT : paramétrer format electroménager Création: 08/sept./10 15:30 Mise à jour: 08/sept./10 15:45 Résolue: 08/sept./10 15:45 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Support entrant |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Jérome Marianne | Attribution: | Jérome Marianne |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Login: | FOIRDISCOUNT |
| Séparateur: | N/A |
| Type de traitement: |
Mise à jour/création annonces avec création produits (écrasement)
|
| Description |
|
Bonjour,
Ayant 1 article à créer, je souhaiterai le faire en mode "automatique" par transfert FTP (/stock/entree) ; Voici les infos dont je dispose (à titre d'exemple) : prix : 299.99 Etat : n (neuf) quantité : 1 Référence interne : bal47256213 code article : 47256213 (ce n° figure sur le lien relatif à cet article) Description : ** MEGA PACK ** BALAIS ASPIRATEUR À 4 BROSSES SANS FIL + CHARGEUR + NETTOYEUR + NOTICE FR (inovatec). _SATISFAIT, ÉCHANGÉ ou REMBOURSÉ/ENVOI SCELLÉ sous 24H/PRO FR/SAV/EN STOCK. Je suppose que cet article est dans la catégorie "électroménager" ? Mes tentatives de création par le biai du répertoire "entree" du FTP (/stock/entree) ont échoué; Pouvez-vous me renvoyer un fichier XLS ( ou CSV) avec mes infos qui fonctionnerait ? N.B.: Vous avez en pièce jointe mon fichier CSV qui n'a pas fonctionné.............. Merci, Cordialement, Philippe FOIRDISCOUNT |
| Commentaires |
| Commentaire de Jérome Marianne [ 08/sept./10 15:45 ] |
| Format paramétré et rajouté dans Config FTP |
[APP-24813] Possibilté d'extraire la base de données (produits + annonces) d'un pro FR pour récupérer les données réexportables sur une autre plateforme price Création: 27/mars/09 08:43 Mise à jour: 30/déc./09 10:02 |
|
| Etat: | Bloqué |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 43.0.2 |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Gaël Seguillon | Attribution: | Dispatcher (Pôle VEN) |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM: | *** STANDBY *** |
| Classif FONC: | commercial |
| Description |
|
Cette extraction nous permettrait de pouvoir importer plus facilement nos catalogues français à l'international, après traduction et adaptation au format type spécifique à chaque pays. Aujourd'hui nous pourrions facilement mutualiser l'offre de certains pros sur les différentes plateformes avec cette solution notamment pour ceux qui ont créé tout leur inventaire manuellement : ex : superpromos et newstyls veulent vendre UK et ES mais n'ont pas de fichiers de stock Le constat - simple : personne sur le plateau technique n'a les outils (programmes) pour faire ce type d'extraction aujourd'hui. Comment avancer : - Gaël, tu dois déterminer si ce cas va se représenter fréquemment - transfert de produits + stock de pays à pays. - Si oui, il faut faire un JIRA APP en bonne et due forme (avec comme observateurs les responsables Dev, BI, Exploit et Param), et la demande sera orientée vers l'équipe la plus apte à s'outiller et fournir les données. |
| Commentaires |
| Commentaire de Benoît Bourdon [ 30/mars/09 18:43 ] |
|
? en fait je ne comprends pas trop la demande ... je n'ai pas non plus l'impression que ce soit bien défini ... Gaël, tu reviens vers moi quand tu veux - on regardera en détail le besoin, histoire de mieux comprendre. |
| Commentaire de Gaël Seguillon [ 30/mars/09 20:25 ] |
|
En fait il s'agit de pouvoir à partir d'un inventaire d'un
pro récupérer ses données annonces + produits, c'est à dire tous les
éléments liés à son annonce (état, code, prix commentaire ...) mais
également assez de données produits pour pouvoir lui réexporter le
fichier avec les valeurs d'attributs suffisantes pour permettre de
traduire un fichier qui est reexportable sur une autre plateforme Price
et permet création produits +annonces c'est assez intéressant pour les ouvertures de catégories UK et ES, on peut se voir rapidement pour se donner un idée de la faisabilité et du coût technique que ça représente ? merci Gaël |
[APP-31399] Fiches produits avec un type de produit complément depuis septembre 2010 Création: 12/oct./10 17:17 Mise à jour: 26/nov./10 09:58 Résolue: 23/nov./10 14:28 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Produits |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 81.1.2 (Clickintext + Redirections NPF FR et ES) |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Agathe Remy | Attribution: | Julien Sananikone |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Bug DECORATION_C - 2010-10-26.xlsx
Bug DECORATION_C.xlsx
|
||||||||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Site: | Prod | ||||||||
| Projets PM: | *** A PLANIFIER *** | ||||||||
| Description |
|
Bonjour,
Suite à une demande d'explication d'un écart entre 2 rapports BI demandée par Hisao-san, nous avons comparé le nombre d'articles global et la somme des nombre d'articles par famille de produit et nous nous sommes aperçu que certains articles n'étaient rattachés à aucune famille de produit parce qu'ils possèdent un type de produit complément : DECORATION_C. Vous trouverez la liste de ces articles en pièce jointe avec les product_id associés : les fiches produits sont elles aussi associées au type de produit complément DECORATION_C. Les premiers articles concernés ont été créés le 13/09/2010 et concerne 88 articles capturés sur septembre, soit un VA d'environ 1 200€. Un rapide comptage nous indique qu'environ 7 000 fiches produits avec un base_product_id non renseigné sont ainsi rattachées au type de produit complément DECORATION_C. Svp, pouvez-vous regarder ce qu'il en est et corriger les données ? Nous sommes à votre disposition si vous avez besoin de plus d'info. Merci, Agathe |
| Commentaires |
| Commentaire de Agathe Remy [ 12/oct./10 17:19 ] |
| Liste des articles avec type de produit DECORATION_C |
| Commentaire de Jérôme Viviès [ 13/oct./10 17:36 ] |
|
Ok, le JIRA est arrivé au bon endroit.
Cela semble lié à une migration de produits que nous avons faite récemment, du type "Jouet" vers le type "Décoration". Le paramétreur en charge du dossier est absent actuellement et sera de retour lundi - il regardera ce problème en priorité. S'il s'agit d'une urgence absolue, merci de le signaler ici + passer me voir. |
| Commentaire de Martin Sudmann [ 14/oct./10 10:49 ] |
|
si ça existe réellement, des cpl sans base_product_id, on a un grave trou dans l'appli...
Ca relève de MEV ou import de fichiers. |
| Commentaire de Agathe Remy [ 14/oct./10 11:05 ] |
|
Je pense que ça peux attendre le début de la semaine prochaine, mais pas beaucoup plus.
A noter qu'après avoir corrigé la configuration des fiches produit et annonces, il faudra également prévoir un script de correction du prd_type_code dans ITEM avec mise à jour de la change_date. A voir aussi s'il n'y a pas des évènements à créer pour maintenir la cohérence des données et s'il n'existe pas d'autres dénormalisations du prd_type_code à corriger... Agathe |
| Commentaire de Benoît Bourdon [ 15/oct./10 14:20 ] |
|
Hello
Après avoir démêlé tout ça ... Concernant la modélisation : Il y a effectivement eu une migration produit Jouet (modélisation simple : produit - annonce) vers décoration (modélisation complément : Produit - Complément - Annonce) La migration se déroule par import et ne fait que modifier le Prd_type_code des produits ---> mais ça ne créer évidement pas de produit base // complément en recréant toutes les liaisons qui vont bien ...etc... La migration d'un type simple vers un type complément est impossible (la réciproque aussi) Dans le coup tous ces produtis (environ 7000) se retrouve physiquement en modèle simple (produit - annonce) mais portent le type produit decoration_C !!! Et donc les item générés à partir de ces produits portent donc (je suppose) physiquement le type decoration_C ... Concernant le données / le reporting : Dans le coup les items sont en decoration_C --> ils ne rentrent dans aucune famille en terme de reporting et ce sur pas mal de rapports (chez Rakut, chez Philippe, chez les commerciaux ...). Correction alternative : affecter les produit complément à une famille dans la conf produit ... à encore ça impacterais un certain noùbre de rapport dans les diverses équipes. Donc pas d'autre solution que de reprendre les données. Solution : 1- Coté modélisation produit : Revenir en arrière : ramener tous les produits dans le type jouet (et identifier si il y a eu d'autre cas similaire - c'est probable, il faut reprendre la demande initiale de Many) : Julien / Fabien ont tous les éléments pour le faire normalement. 2- Coté reporting : prendre en compte ce bug temporairement ... 3- Coté données générée dans les items : Reprendre les données pour les X items considérés : pilotage à faire entre Param et Exploit (mais ça vaut le coup que la requête de migration / réparation soit relue par Manu et Arnaud qui maitrise les domaine modèle produit et item ...) Je vous laisse créer les jiras / demandes ...etc... ------------------------------------- A priori il faudrait faire le point 1 rapidement (lundi ?) pour éviter de générer toujours plus de données erronées dans les items. |
| Commentaire de Julien Sananikone [ 21/oct./10 15:05 ] |
|
j'ai réimporté les produits dans jouets:
http://bo.priceminister.com/datafile_back?action=advfilesearch&file_id=&login=cat-pm1&process_code=&status=&use_proc_date=false&start_date=20%2F10%2F2010&end_date=&order=&x=0&y=0 les erreurs sont dues à des produits qui ont été supprimés entre temps. |
| Commentaire de Agathe Remy [ 26/oct./10 14:56 ] |
| Voici la liste des produits créés hier avec le type DECORATION_C |
| Commentaire de Julien Sananikone [ 26/oct./10 15:17 ] |
|
il reste des mappings dans l'arbre import (exemple : http://bo.priceminister.com/category_back?action=categoryview&categorykey=122286)
--> il faudrait une requête pour les récupérer et les updater |
| Commentaire de Julien Sananikone [ 26/oct./10 16:18 ] |
|
les 2 types codes compléments en erreur sont
2060 : decoration_c 1860 : cosmetique_c |
| Commentaire de Julien Sananikone [ 26/oct./10 17:29 ] |
|
j'ai retiré les références à ces types compléments dans les mappings suivant
SQL> select ctg_parameter.category_id from ctg_parameter, category where category.category_id = ctg_parameter.category_id and ctg_parameter.ctp_type_code = 1000 and ctg_parameter.NUMBER_VALUE IN (1860, 2060) and category.ctg_type_code = 60 ; 2 3 4 5 6 7 CATEGORY_ID ----------- 197990 198004 121740 121750 323689 122289 348533 349835 260551 260560 121614 121741 122285 122286 349852 122284 121720 348529 348530 197991 328548 121620 122306 121719 121743 122283 |
| Commentaire de Julien Sananikone [ 23/nov./10 14:28 ] |
| Toutes les actions de réprataions ont été menées : Param et DBA |
[APP-28479] Problème à nouveau sur 2 cas d'arrondis au centime inférieur sur les livres Decitre se plaint Création: 25/févr./10 13:32 Mise à jour: 10/déc./10 12:05 Résolue: 07/déc./10 14:24 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Annonces |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 83.0.0 (VEN-F) |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Anne Korchia | Attribution: | Benoît Bourdon |
| Résolution: | Aucune correction envisagée | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
BIBLIOGRAPHIE_2010_01_16.zip
BIBLIOGRAPHIE_2010_01_21.zip
|
| Pays: |
FRA - France
|
| Projets PM: | *** RESERVE *** |
| Classif1: | MEV |
| Classif2: | lang |
| Classif FONC: | commercial |
| Description |
|
Voilà le mail de la responsable chez Decitre (decilibris et toutilibris chez PM)
Nous venons de constater à nouveau deux cas d'arrondis au centime inférieur qui font apparaître un marchand avant nous, dans la liste de résultats, alors qu'il est moins bien noté que nous (4.4 alors que 4.6 pour notre boutique toutilibris). Il s'agit de la boutique « DMNEUF », ci-joint les captures d'écran, pour les articles 9782870971154 à 13.77 au lieu de 13.78 ¿ et de la boutique « TDMNEUF » et « lechocdumois » pour 9782350132082 à 18.90 au lieu de 18.91¿. Merci de faire le nécessaire très rapidement car nous sommes pénalisés par cette « tricherie » et de vérifier si d'autres produits de ces marchand sont également avec un prix neuf faux et également si d'autres marchands utilisent aussi cette technique pour biaiser les résultats. |
| Commentaires |
| Commentaire de Gaël Seguillon [ 25/févr./10 14:00 ] |
|
Salut Grosse colère chez Decitre, des vendeurs recommencent à jouer sur l'arrondi, j'ai vu les comptes concernés sur certains ça peut se comprendre car loi Lang débloquée, à ce niveau à nous de faire la police mais d'autres cas plus problématiques de comptes avec option Loi Lang bloquée et offre jouant sur l'arrondi datant de 2010. http://bo.priceminister.com/advert_back?action=advertbackview&advertid=261047601 |
| Commentaire de Benoît Bourdon [ 25/févr./10 15:08 ] |
|
Hello, je viens de creuser le jira : J'ai regardé l'annonce d'un pro en question "lechocdumois" : sur l'écran BO, on voit que son annonce n'a pas été faite / modifiée par fichier d'import et donc elle vient du front office et date du 21/01/2010. --> donc j'ai essayer de reproduire le problème en integ. Ensuite j'ai aussi essayé de jouer avec les arrondis ... rien à faire on ne peut pas passer outre la loi lang ... et donc si je regarde la fiche produit sur l'Integ. http://bo.pm.lan/referential_back?action=productview&productid=92665196 (qui est une image de la prod ayant quelques semaines d'ancienneté) La fiche produit concernée à un prix d'origine à 18.90 --> le Pro à tout à fait le droit de mettre son annonce à 18.90 ... et la Mev fonctionne bien. Ensuite je suis aller voir la fiche produit en prod : http://bo.priceminister.com/referential_back?action=productview&productid=92665196 là le prix d'origine est différent et est à 19.90 --> J'ai l'impression que le prix d'origine a changé suite à un import fait après le 21 janvier 2010 ... --> Est ce qu'on peut fouiller coté import sur les derniers fichiers qui ont touchés ce produit svp ? |
| Commentaire de Gaël Seguillon [ 25/févr./10 15:36 ] |
|
cool ça voudrait dire que ça fonctionne bien mais que c'est du à une modification du prix de référence. Jerôme on peut voir côté Catalogue ? merci Gaël |
| Commentaire de Marion Anfreville [ 25/févr./10 17:00 ] |
|
Bien pensé. Un chance qu'on copie encore les fichiers de mise à jour decitre en sauvegarde (jusqu'à une certaine date...) sinon je n'aurais pu vous donner cette info. Ce qu'on constate dans les mises à jour decitre : BIBLIOGRAPHIE_2010_01_16.zip:9782350132082 9782350132082 Histoires secrètes d'une imposture Jean-Claude GawsewitchµParisµFrance 235013 Coup de gueule SODIS 3012600500000 GodardµBrunoµ1µ1µµµµµ 22.00 x 14.00 x 2.00 cm 0.3250 253 16/01/2010 14/01/2010 01/01/2010 21/01/2010 Photo : copyright A. Bertram. Sports Sport Football 18.90 17.91 5.50 Broché Disponible 16/01/2010 BIBLIOGRAPHIE_2010_01_21.zip:9782350132082 9782350132082 Histoires secrètes d'une imposture Jean-Claude GawsewitchµParisµFrance 235013 Coup de gueule SODIS 3012600500000 GodardµBrunoµ1µ1µµµµµ 22.00 x 14.00 x 2.00 cm 0.3250 253 16/01/2010 14/01/2010 01/01/2010 21/01/2010 Photo : copyright A. Bertram. Sports Sport Football 19.90 18.86 5.50 Broché Disponible 16/01/2010 En gros, dans le fichier du 16/01/2010, le prix d'origine est encore de 18.90 euros. A partir du fichier du 21/01/2010, le prix d'origine est à 19.90 euros. Les fichiers soumis sont en pj du jira. |
| Commentaire de Espérance Galouo-Lece [ 26/févr./10 10:56 ] |
| - Vu qu'il s'agit d'une éventuelle mise à jour de prix venant de Decitre, le Jira peut-il être résolu ? |
| Commentaire de Anne Korchia [ 26/févr./10 15:08 ] |
|
pour le cas du premier sbn un pro arrive à passer l'ouvrage à 12.55 euros alors que ses droits Loi Lang sont bloqués http://bo.priceminister.com/offer/buy/86134887/van-hamme-jean-blake-et-mortimer-tome-19-la-malediction-des-trente-deniers-livre.html |
| Commentaire de Marion Anfreville [ 26/févr./10 15:56 ] |
|
Je ne saurais dire si c'est le même cas de figure (histoire
de MAJJ Decitre) pour cette annonce car la dernière mise à jour du
produit date du 18/11/2009 et le prix d'origine est le même
qu'actuellement, soit 14,50 euros. BIBLIOGRAPHIE_2009_11_18.zip:9782870971154 9782870971154 La malédiction des trente deniers Les aventures de Blake et Mortimer Tome 19 Tome 1, Le manuscrit de Nicodemus Blake Et Mortimerµ µBelgique 287097 MDS 3019000100000 Van HammeµJeanµ1µ1µ0µµµµ ; SterneµRenéµ2µ1µ0µµµµ ; De SpiegeleerµChantalµ3µ1µ0µµµµ ; CroixµLaurenceµ4µ0µ0µµµµ 31.50 x 23.80 x 1.20 cm 0.5200 56 18/11/2009 20/11/2009 01/11/2009 20/11/2009 BD tout public Policier/Espionnage Policier/Espionnage 14.50 13.74 5.50 Album Disponible 18/11/2009 (j'ai les copies des MAJ decitre jusqu'au 15/10/2009). Toutefois, la fiche produit a été créé par MeV FO => utilisateur "mouchtio" et a été mis à jour par la suite par Decitre. |
| Commentaire de Edouard Gomez-Vaez [ 08/avr./10 17:19 ] |
|
Pour ce dernier cas, j'ai essayé de modifier l'annonce à
partir du FO, et j'ai bien le message d'interdiction loi Lang. Pourtant le prix de l'annonce a été modifiée le : 12/01/2010-00:02 Vendeur réduit prix Active Ancien prix : 12,83 Euros Quant au produit, son prix d'origine ne semble pas avoir été modifié d'après Marion. Ce n'est pas une histoire d'arrondi, puis que la limite Lang est à 13.78... Je ne comprends pas ce qui s'est passé. |
| Commentaire de Manuel Sadok [ 26/oct./10 16:30 ] |
| Ben, c'est toujours d'actualité ? |
[APP-27115] Mise à jour Nbre d'articles sur Home Création: 19/oct./09 18:50 Mise à jour: 29/déc./10 16:23 Résolue: 24/déc./10 10:03 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Home Page |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 83.0.2.1 |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Pierre Krings | Attribution: | Ariane Baldinger |
| Résolution: | Corrigé | ||
| Σ Estimation restante: | 0 minutes | Estimation restante: | Non spécifié |
| Σ Temps consacré: | 10 minutes | Temps consacré: | Non spécifié |
| Σ Estimation originale: | Non spécifié | Estimation originale: | Non spécifié |
| Description |
|
Vu la difficulté à afficher un nombre d'items cohérent sur
la HP qui soit directement pris dans le système (en raison notamment des
variations imports), il a été décidé de mettre à jour manuellement et
mensuellement à partir d'un prévisionnel établi à l'avance. Charge à moi
de vérifier que les chiffres sont inférieurs à la réalité des stocks
(disponible dans le BI). Le prévisionnel 2010 est donné ci-dessous et devra être mis à jour le 1er de chaque mois ou bien le 1er jour ouvrable possible suivant cette date. 01/11/2009 130 615 497 01/12/2009 134 160 787 01/01/2010 138 126 048 01/02/2010 145 995 577 01/03/2010 149 813 941 01/04/2010 153 550 510 01/05/2010 157 459 231 01/06/2010 161 021 186 01/07/2010 165 700 204 01/08/2010 167 276 038 01/09/2010 173 369 913 01/10/2010 180 395 181 01/11/2010 185 514 000 01/12/2010 192 107 828 01/01/2011 198 188 756 |
| Commentaires |
| Commentaire de Marion Anfreville [ 28/déc./09 12:53 ] |
|
Emplacement du label : /default/Labels/_Navigation/FrontHeader/lbl_item_count |
| Commentaire de Marion Anfreville [ 28/mai/10 09:41 ] |
| Merci de ne pas fermer cette demande car les sous-tâches, qui sont ouvertes au fur et à mesure, vont jusqu'à 2011. |
| Commentaire de Ariane Baldinger [ 24/déc./10 10:03 ] |
|
les sous-tâches ont été résolues.
Pierre, Si tu souhaites d'autres mises à jour pourrais-tu ouvrir un nouveau jira stp ? Merci |
[APP-27973] Utilisation du filtre Last Tracking 30 jours dans les tags pour nos partenaires en Affiliation Création: 14/janv./10 14:21 Mise à jour: 10/déc./10 17:01 Résolue: 07/déc./10 19:49 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Affiliation |
| Affecte la/les version(s): | 59.0.3 |
| Version(s) corrigée(s): | 82.0.2.2 |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Jonathan Gorges | Attribution: | Dispatcher (Pôle CTN) |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM: | *** RESERVE *** |
| Classif FONC: | webanalytics |
| Description |
|
Bonjour,
Nous avons décelé un problème en décembre dans la manière dont nous rémunérions nos partenaires en Affiliation. Le problème: En affiliation, nous rémunérons nos affiliés uniquement pour des paniers Last Tracking 30 jours. Ce filtre "last tracking 30 jours" est une donnée utilisée uniquement par Business Object. Le processus de validation des ventes est aujourd'hui le suivant : nous communiquons 100% des paniers réalisés par les affiliés de chaque plateforme via leur tags, puis nous demandons aux plateformes de ne valider que les paniers "Last tracking 30 jours" en utilisant des reporting BI qui filtrent les mauvais paniers (Last tracking > 30 jours). Nous nous sommes aperçu en Décembre que les reporting utilisés ne possédaient pas ce filtre "Last Tracking 30 jours" et donc que nous surpayions nos partenaires en leur payant des ventes dont les tracking avaient été créés plusieurs mois auparavant... Ce problème existait depuis plusieurs mois. Sur Décembre 2009, nous avons donc éviter de payer de justesse 12.000 paniers sur 36.000 ! L'impact financier peut-être très rapidement important. La solution: Afin d'éviter que ce problème ne se reproduise, la solution consiste à intégrer directement le filtre "Last Tracking 30 jours" dans l'information que nous communiquons aux plateformes. L'objectif: Garder en base toute l'information relative aux paniers créés sur PriceMinister via l'affiliation, mais ne communiquer aux plateformes QUE les paniers "Last Tracking 30 jours". Avec cette amélioration, plus aucune erreur humaine ne sera possible. Nous garderons les filtres "Last Tracking 30 jours" dans les rapports BI utilisés, juste par sécurité ! Les partenaires concernés: Pour le moment, seul le canal affiliation est concerné. Les partenaires concernés sont donc : Effiliation, Zanox, Affilinet. Je reste à votre disposition pour toute information complémentaire. Merci d'avance pour votre retour et excellente journée. JG |
| Commentaires |
| Commentaire de Fabrice Feugas [ 07/déc./10 19:49 ] |
|
Corrigé depuis un moment :)
Ca fonctionne bien JO ? |
| Commentaire de Jonathan Gorges [ 08/déc./10 08:48 ] |
|
Oui oui, cela fonctionne parfaitement.
Merci |
[APP-20934] pb tracking souhait Création: 23/juin/08 15:19 Mise à jour: 13/janv./09 11:41 Résolue: 21/juil./08 18:23 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Souhaits, Tracking |
| Affecte la/les version(s): | 23.0.3 |
| Version(s) corrigée(s): | 38.0.0 (TX-D Bis) |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Olivier Mathiot | Attribution: | Pierre Bret |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
QDC juin 08 wish.xls
|
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM: | *** RESERVE *** |
| Description |
|
chute de volume d'affaire et des visites associés au tracking de souhaits observés par thomas en VA dans BI : 2007/11 2007/12 2008/01 2008/02 2008/03 2008/04 409877,01 446175,32 451933,79 343959,2 169677,29 118085,31 analyse de quentin : La chute correspond tres précisemment a la mise en place du sharp tracking (voir PJ) http://pricejira.lan/browse/APP-19413 Il s'agit donc visiblement bcp + d'une chute liée à un bug dans la mesure des entrées que rééllement du VA. 2 options : 1. le sharp tracking est buggé **au niveau de la capture côté serveur** => je ne pense pas car on s'en serait rendu compte sur d'autres cas => mais si c'est ca c'est grave qu'on ne s'en soit pas rendus compte + tôt ! 2. le sharp tracking est buggé **dans les mails** : certains logiciels de messagerie pourraient ne pas transmettre la partie située après le # au browser lors du clic sur le lien => je penche plutot pour ca Swan / Pierre : A creuser, tester, vérifier !!! Vous pouvez mettre un Jira je pense... |
| Commentaires |
| Commentaire de Olivier Mathiot [ 23/juin/08 15:25 ] |
| ci joint analyse des chiffres souhaits sous XLS par QDC |
[APP-19687] [CoSAV]Possibilité de limiter l'accès aux pages nécessitant d'etre logué si l'utilisateur utilise un anonymizer? Création: 20/févr./08 16:29 Mise à jour: 08/juil./09 10:36 Résolue: 02/juil./09 14:48 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 19.0.2 |
| Version(s) corrigée(s): | 49.0.0 (TX-H) |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Cedric Favero | Attribution: | Dispatcher (Pôle TX) |
| Résolution: | Aucune correction envisagée | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM: | *** RESERVE *** |
| Classif FONC: | CoSAV |
| Description |
|
Je pense qu'il s'agit de questions liées à la sécurité et
donc concernant Ange Ferrari mais je poste le JIRA en l"état pour voire
toutes les implications. Nous constatons depuis le passage au gratuit des annonces auto une hausse importante des annonces auto frauduleuses. Actuellement on peut estimer le nombre d'annonces frauduleuses détectées, avérées et supprimées à 10/15 par jour! Chacune peut entrainer plusieurs milliers d'euros d'arnaque et Price etre considéré comme responsable. Un certain nombre d'outils de surveillance ont été mis en place par mots clés , notamment sur les IP et qui fonctionnent tres bien. Toutefois les comportements commencent à se modifier et certains fraudeurs réussissent à passer entre les premieres mailles du filet , notamment en dissimulant leur réelle adresse IP , à priori par le biais de logiciels "anonymizers" les faisant apparaitre dans d'autres pays (Allemagne , USA, etc...) alors que nous surveillons particulièrement certaines adresses (comme le Benin ou la Roumanie). Ma question est la suivante : serait-il possible d'envisager de bloquer l'accès aux pages du site nécessitant d'etre logué (mon compte/ mise en vente/etc... ) dans le cas où l'on détecte l'usage d'un tel logiciel anonymizer? A-ton déjà un blocage en fonction de l'usage ou non des cookies? Saurait-on le faire et celà serait-t-il envisageable? Merci pour tous vos éventuels retours. |
| Commentaires |
| Commentaire de Ange Ferrari [ 20/févr./08 16:46 ] |
|
Cedric peux tu me montrer un exemple d'annonce frauduleuse datant d'aujourd'hui ou d'hier que je puisse faire des recherches pour identifier le comportement du vendeur sur le site ? |
| Commentaire de Cedric Favero [ 20/févr./08 16:54 ] |
|
Exemple de compte: Ilona27 http://bo.priceminister.com/user_back?action=userview&user_account_id=15991763&show_event_login=true#events Lors de la création de l'annonce il avait une IP que nous n'avons pas en mot clé: 78.47.210.72 (on peut en rajouter à l'infini) Par contre par la suite on a des IP AOL ou une IP Roumanie qui nous auraient permis de tomber sur lui car on a les plages en mot clé. |
| Commentaire de Cedric Favero [ 20/févr./08 16:55 ] |
|
Ou sinon j'avais aussi une personne avec un nombre important de comptes. Tous avec le meme mot de passe: 2g6v27a (que l'on a mis en mot clé) mais avec des adresses IP à tous les coins du monde http://bo.priceminister.com/user_back?action=usersearch&javascript_callback=&login=&password=2g6v27a&user_account_id=&last_name=&usr_type_code=&permission_type=&permission_value=false&usr_presence_code=&usr_visibility_code=&coupon_secret_name=&reliability=&email=&compensation=&usr_privilege_code=&start_date=&end_date=&start_connection=&end_connection=&ip_address=&number_rows=200&x=0&y=0 |
| Commentaire de Ange Ferrari [ 20/févr./08 18:14 ] |
|
en fait il est assez difficile de bloquer quelqu'un qui utilise un proxy: pour se logger il est obligé d'accepter les cookies ( le cookie de session ) pour ce qui est de l'ip le seul controle que l'on pourrait rajouter c'est un controle sur la provenance de l'ip qui n'est pas française en théorie un vendeur qui vend sa voiture sur price est en france ? on possède la liste des plages d'@ ip des ISP français. Ensuite on peut ( et on le fait déjà ) bloquer l'accès à tout ou une partie du site à une IP ( ce qui nous permet d'empêcher certains crawler ) par contre il faut qu'on récupère la liste des IP que vous bannissez |
| Commentaire de Cedric Favero [ 21/févr./08 13:50 ] |
|
En fait on ne veut pas non plus bloquer complétement l'accès car du coup c'est totalement visible pour eux. Avec notre systeme , ils ne se rendent pas obligatoirement compte que leurs annonces sont invisibles. De plus , il faut toujours un controle humain. ex: on met des IP Afrique en surveillance mais tout le monde a le droit d'aller en vacances au Maroc ou à l'Ile Maurice... Je voulais juste savoir si d'une maniere ou une autre il était possible de pister une personne provenant d'un proxy ou empecher le log lorsque'on detectait l'usage d'un tel outil. (je crois que c'est le cas sur ebay) Après on ne mettra jamais toutes les IP en surveillance non plus... Je suis par contre interessé par la liste des plages IP des ISP français, çà peut servir. Et vais voir aussi si je trouve également les plages de certains relais "anonymes". Merci. |
| Commentaire de Ange Ferrari [ 03/mars/08 10:50 ] |
|
Pour les plages d'adresses IP FR il y a une liste la http://www.completewhois.com/statistics/data/ips-bycountry/rirstats/FR-cidr.txt |
| Commentaire de Emeric Teil [ 02/juil./09 14:48 ] |
| L'Auto étant maintenant migrée... |
[IMP-5703] Maintenance Import - HeureH : problème de référence SKU Création: 01/avr./10 10:26 Mise à jour: 05/mai/10 13:41 Résolue: 05/mai/10 13:41 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Demande commerciale |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Maram Khayati | Attribution: | Jérome Marianne |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Modele_d_export_PM_pour_Bijoux-2010_03_18_11.csv
screenshot-1.jpg
Tic Tac Time - PM (Bijoux) - 10-03-2010.csv
|
| Pays: |
FRA - France
|
| Login: | HeureH |
| Séparateur: | N/A |
| Type de traitement: |
N/A
|
| Description |
|
Message d'origine----- De : thierry.vernhes@tvdistrinet.com Envoyé : 2010-03-29 11:16:26.0 A : Priceminister Objet : Tictactime : PB de transmission de SKU des commandes Client Société : Tictactime 0320575333 (jerome.detre@tvdistrinet.com) Bonjour, Il semble qu¿il y ait eu des soucis sur plusieurs commandes passées chez vous. Les articles commandés par les clients ne sont pas ceux qu¿ils attendaient. - 84159055 (http://www.priceminister.com/purchase?action=saleview&purchaseid=84159055 ) - 84267440 (http://www.priceminister.com/purchase?action=saleview&purchaseid=84267440 ) Il semble que la raison soit que les SKU que vous nous transmettez par le biais des commandes ne sont pas toujours les bons (Souvent pour des bijoux). Dans la commande 84159055, le SKU transmis est le 80353 alors que ce devrait être 79358 Dans la commande 84267440, le SKU transmis est le 67166 alors que ce devrait être 67387 (pourtant correct dans notre inventaire PM : http://www.priceminister.com/inventory?sort=&category=advert_clothing&keyword=Rt-61109&submitbtn=&category_search_ref=advert_clothing_search_all ) En vérifiant sur d¿autres commandes, ce ne sont pas les seules, il y a aussi : 84305322 84290079 84277457 84048335 83512417 84094218 83534544 Pouvez vous jeter un ¿il assez rapidement ? Car les acheteurs sont susceptibles de recevoir des articles dont le prix ne correspond pas à ce qu¿ils paient réellement.. (Dans les 2 sens) Cordialement, Jérôme DETRE |
| Commentaires |
| Commentaire de Maram Khayati [ 08/avr./10 15:10 ] |
|
Le pro est revenu vers moi, Pouvez-vous faire quelque chose ? merci |
| Commentaire de Jérome Marianne [ 13/avr./10 11:34 ] |
| Il faut demander au pro de nous envoyer son dernier fichier de création produit bijoux pour qu'on puisse voir s'il n'aurait pas réutiliser des références. |
| Commentaire de Maram Khayati [ 13/avr./10 11:49 ] |
| Envoi mail au vendeur. Support pro en copie. Merci |
| Commentaire de Maram Khayati [ 13/avr./10 16:42 ] |
|
Retour du PRO par mail. --" Voici les 2 derniers fichiers de création bijoux (généré par Neteven, notre prestataire)." Merci |
| Commentaire de Jérome Marianne [ 14/avr./10 14:09 ] |
|
Le problème vient du fait que le pro utilise des références
identiques pour des produits differents. Voir un ex en copie d'écran. Il utilise la ref 80897 pour un bijou Phebus et pour un bijou Dolce Gabbana. Du coup 2 annonces se mettent sur la fiche produit 80897 et forcement une n'est pas bonne. |
| Commentaire de Jérome Marianne [ 14/avr./10 14:19 ] |
|
Étant donné que le pro fait du multiformat et fait des maj
neteven tous les jours on ne peut pas vider tout son stock et supprimer
toutes ses fiches produits. C'est donc au pro de vérifier ses références produits en doublon qui posent problèmes et de ne plus les utiliser car il y a eu des mélanges d'informations, ou alors de nous donner les références produits en doublons qui posent problème pour qu'on les supprime et repartir sur des bonnes bases pour ses prochains imports. Il est important de sensibiliser les pros sur l'importance des références uniques. |
| Commentaire de Maram Khayati [ 14/avr./10 14:27 ] |
|
J'en ai informé le PRO. J'attend donc son retour. Merci |
| Commentaire de Isabelle Weisbecker [ 21/avr./10 11:26 ] |
| Ajout de Dorian en obseravteur pour suivi Neteven. |
| Commentaire de Dorian Porta Delsol [ 28/avr./10 16:27 ] |
|
Voici le retour de Neteven : "J'ai mis un certain temps à remonter la boucle de ce problème. J'avoue ne pas avoir compris de quoi il s'agissait à première vue car je n'étais pas dans la boucle du service paramétrage attendant un retour. Je comprend que HeureH a des erreurs de visuels dans ses annonces PM. Quelqu'un a fait une demande pour supprimer les fiches ? pas chez nous en tout cas. Le catalogue de HeureH contient des SKU unique qui sont des déclinaisons de taille, coloris, elles-mêmes réunies sous un SKU Père. Dans les fichiers de création, nous venons de comprendre que le marchand utilise un SKU père en tant que Référence Modèle et un SKU unique dans Référence Annonce, ce qui donne : Référence Modèle | Référence Annonce 87346 87542 87346 87543 87346 87544 87346 87545 87346 87346 Penses-tu que cela puisse générer des incohérences de ton coté au moment de la publication des annonces ? Pour rappel, la question du SKU père avait été abordé avec Skikom. Les SKU Pères sont-il supportés par la plateforme? Si nous déposons un fichier de création à jour avec ces mêmes SKU, les fiches présentes seront-elles écrasées? Nous avons par sécurité clôturer les annonces Bijoux de HeureH." Merci de ton retour Jérome. |
| Commentaire de Jérome Marianne [ 29/avr./10 10:36 ] |
|
Le problème qui se pose ici est que certains SKU père
identiques sont utilisés pour des produits différents, je reprend l'ex
cité précédemment du SKU père 80897qui est utilisé pour un bijou Phebus
et pour un bijou Dolce Gabbana. Si le pro n'arrive pas à gérer cela il n'a qu'a prendre les références annonces qui sont uniques et les utiliser aussi pour les références modèles, comme ça on créera une fiche et une annonce par référence et cela résoudra le problème de doublons. |
| Commentaire de Jérome Marianne [ 05/mai/10 13:41 ] |
| Pour régler le souci de SKU le pro doit prendre les références annonces qui sont uniques et les utiliser aussi pour les références modèles, comme ça on créera une fiche et une annonce par référence et cela résoudra le problème de doublons. |
[BCK-258] (ES) (Affiliation) Partenariats directs en Espagne - Suivi CA sur XITI par partenaire externe Création: 04/janv./11 12:06 Mise à jour: 27/janv./11 18:43 |
|
| Etat: | Ouvert |
| Projet: | Backlog Projets |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Nouvelle fonctionnalité | Priorité: | Majeur |
| Rapporteur: | Isabel Yus | Attribution: | Dispatcher (Pôle CTN) |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ESP - Espagne
|
| Projets PM: | *** RESERVE *** |
| Classif FONC: | webanalytics |
| Description |
|
Bonjour,
Nous avons de « petits » partners avec lesquels nous pouvons quelques ventes par mois en Espagne. Pour cela il serait intéressant de pouvoir isoler ces données séparément avec des chiffres sur les accès directs et non directs, le VA et le CA sur Xiti - Pourquoi ? Parce qu'il s'agit de sites qui n'ont pas de tag (pixels) à nous communiquer puisqu'il s'agit de sites de contenu qui ne travaillent pas à la perf: Ils ne veulent pas non plus passer par une plateforme d'affiliation. Notre objectif en Espagne étant de les développer en tant que réseau Price «bien ciblé », nous devrions trouver le système pour isoler ces données sur XiTi. Le problème vient du fait que sur XiTi le site de niveau 1 « tracking1 » se base sur du first_tracking et ne montre pas le CA et le VA. Pour l'instant nous avons eu juste une demande et nous sommes en train d'utiliser un rapport BI comme "sortie de secours". En revanche, il nous faudrait dans l'avenir à court terme en Espagne (2 mois maxi) un tag XiTi spécifique comme on peut le faire avec d'autres partenaires. Nous venons d'avoir une autre demande de ce type, la première étant formulée par le site de contenu video, Ultima Game et la 2ème provenant d'un magazine culturel online appelé MySofa. Merci d'avance pour votre réponse sur le délai de traitement de cette demande, Isabel |
[APP-30434] Affiliation - Changement sur les tags des plateforme d'affiliation (Effiliation - Zanox - Affilinet) afin de ne plus remonter les paniers avec un last tracking > 30 jours. Création: 15/juil./10 17:52 Mise à jour: 04/oct./10 14:53 Résolue: 23/sept./10 11:20 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Affiliation |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 78.0.0 (CTN-TU) |
| Type: | Amélioration | Priorité: | Critique |
| Rapporteur: | Jonathan Gorges | Attribution: | Dispatcher (Pôle CTN) |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM: | *** RESERVE *** |
| Classif FONC: | monétisation |
| Description |
|
Bonjour, Je ressors un vieux sujet évoqué notamment en décembre 2009 dernier ( Ce jira a pour but de mettre fin à de longues discutions inutiles entre PM et les plateformes d'affiliation concernant chaque mois des milliers de paniers pour lesquels les plateformes réclament une rémunération, alors que ces derniers ne sont pas "payables" selon notre système de tracking (car last tracking > 30 jours). ** Constat - En affiliation, nous rémunérons aux affiliés tous les paniers trackés dont la différence entre la date d'autorisation et celle du dépôt du cookie du tracking est < ou = à 30 jours. - Cette notion de "last tracking 30 j" est une notion BI uniquement. - En effet, nous remontons également (via le tag de la plateforme) tous les paniers ayant un last tracking > 30 jours. - Ces paniers sont (normalement) supprimés manuellement par nos soins via un processus manuel de validation des ventes, où nous corrigeons avec nos rapports BI tous les paniers remontés à la plateforme qui n'ont pas été capturés ou qui ont un last tracking > 30 j. ** Problème - Chaque mois, ce sujet réapparaît et les plateformes d'affiliation nous demandent de payer des milliers de paniers ayant un LT > 30 jours... ! - Les plateformes d'affiliation réclament le payement de ces paniers car elles enregistrent de leur côté un clic affilié juste avant l'achat. Voici un exemple qui explique pourquoi : 1. Le 01 janvier 2010, un internaute clique sur une bannière d'un affilié Effiliation, se rend sur PM, se logue mais n'achète pas. 2. Nous enregistrons en base le tracking Effiliation. 3. Le 15 février, donc plus de 30 jours plus tard, le même internaute se rend directement sur PM, sans passer par un lien tracké, et achète. 4. Nous remontons la vente (le tag Effi se déclenche), mais ce panier n'est pas payable car last tracking > 30j. Il est mis « EN ATTENTE » côté Effiliation. 5. Durant sa session (session ouverte naturellement), l'internaute peut cliquer n'importe où sur la toile (chez un cashbacker, un couponneur, un emaileur)... Effiliation enregistre donc un clic de son côté, juste avant l'achat... Effiliation croit donc que ce panier doit lui être payé. 6. Cependant, notre système de tracking ne prend pas en compte ce clic, car c'est la visite directe qui a permis l'ouverture de la session. Tout ce qui se passe durant la même session ne peut venir perturber le last tracking. ** Solution - Pour en finir avec ce sujet et mettre fin à ce discourt de sourds avec les plateformes, il serait judicieux de ne plus remonter aux plateformes (via leur tag) tous les paniers ayant un last tracking > 30 jours. - En d'autres termes : la suppression des paniers LT > 30 jours ne doit plus se faire à postériori viaà un processus manuel de notre part, mais bien en amont. Les plateformes d'affiliation ne doivent plus remonter une seule vente ayant un LT > 30 jours. Ce sujet étant assez sensible (car il touche à la rémunération des partenaires) et important, il serait utile de l'évoquer en CO-Market. Je reste à votre disposition pour toute information complémentaire ou pour en parler de vive voix. Merci d'avance pour votre retour. Jon |
| Commentaires |
| Commentaire de Fabrice Feugas [ 22/juil./10 17:20 ] |
|
En effet, ça serait judicieux d'en parler en CoMarket, via Odile. |
| Commentaire de Jonathan Gorges [ 18/août/10 12:04 ] |
|
Hello, Suite au dernier CoMarket et à la nécessité de prioriser ce Jira, j'aimerai insister sur un point en particulier qui a peut-être mal été expliqué. Comme vous le savez, les sites éditeurs (affiliés) ont le choix parmi plus de 30.000 programmes d'affiliation en France. Plusieurs critères sont importants pour un affilié dans le choix d'un programme d'affiliation : la rémunération de l'annonceur, son taux de transfo, son panier moyen et son taux de rejet... Les affiliés PriceMinister pensent que nous avons un taux de rejet avoisinant les 18% ! Cette considération est catastrophique et très loin de la réalité. Ce taux est en effet "artificiellement" haut car nous remontons des milliers de ventes LT > 30 j aux plateformes que nous rejetons manuellement à posteriori durant notre processus de validation des ventes. Nous ne devrions en aucun cas inclure ces paniers inutiles de ce taux de rejet ; pourtant les plateformes et les affiliés le font... Aussi, il n'est juste pas judicieux de notre côté de remonter des ventes (non payables) à des partenaires pour les rejeter juste après manuellement. Ces derniers mois, nous constatons de plus en plus de retours des plateformes et des affiliés qui se plaignent du très fort taux de rejet de PriceMinister. Certains affiliés ne veulent même plus relayer le programme à cause de ces mêmes (fausses) raisons. Ce Jira a été ouvert en priorité majeur, mais il s'agit réellement d'un problème critique et préoccupant... N'hésitez pas à revenir vers moi si vous avez la moindre question. Pourriez-vous svp me donner plus de visibilité sur l'avancement de ce projet ? Par avance merci. |
| Commentaire de Fabrice Feugas [ 18/août/10 17:24 ] |
|
Hello, Merci pour ce retour très complet :). Odile nous a rappelé l'importance de ce JIRA en CoMarket ce matin et nous allons donc le traiter rapidement, au détriment du jeu vendeur. A noter cependant, il ne sortira pas en prod avant notre prochaine version le 05/10... |
| Commentaire de Swan Desportes [ 23/sept./10 11:20 ] |
| Désormais tous les matching de promo en last tracking ne sont fait que si le LT a moins de 30 jours. |
| Commentaire de Cédric Goldovsky [ 04/oct./10 14:53 ] |
| Ok, vu avec Swan. |
[BIN-362] [Espagne/Fraudes] : Rapports transactions entre comptes pour l'ESPAGNE Création: 27/août/07 13:58 Mise à jour: 23/oct./07 10:46 Résolue: 21/sept./07 15:24 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | BackOffice |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Nouvelle fonctionnalité | Priorité: | Majeur |
| Rapporteur: | Sebastien Bruzzone | Attribution: | Samir Beghdadi |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ESP - Espagne
|
| Description |
|
Bonjour, Nous avons un rapport édité quotidiennement concernant les transactions entre comptes pour la France : il est dans http://intra.priceminister.com/stats/reports/public/BackOffice/ et son nom : fraud_seller_buyer_.txt.gz En raison de fraudes similaires sur l'Espagne, nous aimerions avoir le même rapport pour ce pays. Merci. |
| Commentaires |
| Commentaire de Agathe Remy [ 07/sept./07 18:49 ] |
|
Sébastien, Le rapport que tu utilises sur la France est généré par l'ancien système de reporting. Hors, nous n'avons pas d'architecture équivalente pour l'Espagne. En revanche, nous pouvons développer un rapport BusinessObjects. Dans ce cas, il faudra que je transfère ta demande dans le projet BusinessIntelligence. Peux-tu me confirmer que cela vaut le coup que nous passions du temps à développer ce nouveau rapport dans BI? Merci:-) Agathe |
| Commentaire de Sebastien Bruzzone [ 18/sept./07 08:18 ] |
|
Bonjour Agathe, Oui nous avons absolument besoin de ce rapport car nous avons eu de gros problèmes de transactions entre comptes sur l'Espagne. Nous avons detecté un peu tardivement ces commandes et on aurait pu les detecter bien avant si nous avions eu le rapport pour l'Espagne. Merci ;-) Sébastien |
| Commentaire de Agathe Remy [ 18/sept./07 19:17 ] |
|
Samir, Voici un nouveau rapport BI qu'il faudra déployer en France et en Espagne. cf la requête sur titan: /data/priceminister/reporting/platform/prod/sql/sources/backoffice/fraud_seller_buyer.sql Merci:-) Agathe |
| Commentaire de Agathe Remy [ 19/sept./07 11:53 ] |
|
Samir, Voici la requête qui sera à implémenter dans le rapport BI : SELECT TO_CHAR(PURCHASE.AUTHORIZATION_DATE, 'YYYY/MM/DD') ||'|'|| PURCHASE.PURCHASE_ID ||'|'|| ITEM.ITEM_ID ||'|'|| CASE WHEN (ITEM.CLOSING_DATE-ITEM.COMMIT_DATE)<1 AND ITEM.CLOSING_DATE>=TRUNC(SYSDATE - 7) AND ITEM.COMMIT_DATE>=TRUNC(SYSDATE - 7) THEN 1 ELSE 0 END FROM PURCHASE, ITEM, USER_ACCOUNT SELLER, USER_ACCOUNT BUYER WHERE PURCHASE.PURCHASE_ID=ITEM.PURCHASE_ID AND ITEM.BUYER_ACCOUNT_ID=BUYER.USER_ACCOUNT_ID AND ITEM.SELLER_ACCOUNT_ID=SELLER.USER_ACCOUNT_ID AND BUYER.IP_ADDRESS=SELLER.IP_ADDRESS AND PURCHASE.PCH_STATUS_CODE IN (80, 90, 100) AND ITEM.ITM_STATUS_CODE IN (30, 40, 70) AND PURCHASE.AUTHORIZATION_DATE>=TRUNC(SYSDATE - 7) AND SUBSTR(PURCHASE.IP_ADDRESS,1,7)<>'195.93.' ORDER BY TO_CHAR(PURCHASE.AUTHORIZATION_DATE, 'YYYY/MM/DD'), PURCHASE.PURCHASE_ID, ITEM.ITEM_ID ; Merci:-) Agathe |
| Commentaire de Samir Beghdadi [ 21/sept./07 10:59 ] |
|
Agathe, A toi de jouer maintenant, le rapport Developement / Backoffice/Fraude - Transactions entre comptes est enfin prêt pour validation en Dev. Merci, samir |
| Commentaire de Sebastien Bruzzone [ 23/oct./07 10:44 ] |
| ok c'est réglé, merci |
[DEC-642] [Seller macros] : Rapports vente cassé Création: 09/janv./09 19:37 Mise à jour: 25/févr./09 11:35 Résolue: 20/janv./09 18:20 |
|
| Etat: | Fermé |
| Projet: | Reporting |
| Composants: | Marketing |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Charlotte Fachan | Attribution: | Dalila Belkebir |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Il semble que les rapports vente soient cassés : http://intra.priceminister.com/stats/reports/confid/executive/seller/macro/ le nombre de vente par mois est vraiment très très faible :-( merci Charlotte |
| Commentaires |
| Commentaire de Patrice Boulanger [ 13/janv./09 14:36 ] |
| Plutôt du BI non ? |
| Commentaire de Agathe Remy [ 13/janv./09 14:48 ] |
|
Bonjour Thomas, Peut-on en savoir un peu plus : - de quel rapport(s) parlez-vous ? individual_sales_2008-Q4.txt.gz ou individual_sales_2009-Q1.txt.gz ?advert_deposit_2008-Q4.txt.gz ou advert_deposit_2009-Q1.txt.gz ? Les 2 ou les 4? - quel est le nb de ventes moyen par mois ? Merci. Agathe |
| Commentaire de Charlotte Fachan [ 19/janv./09 11:58 ] |
|
Bonjour Agathe, cela concerne les rapports vente "individual sales" et "advert deposit" de Q4 2008. Les données s'arrêtent au 26/12. Merci Charlotte |
| Commentaire de Agathe Remy [ 19/janv./09 13:24 ] |
|
Bonjour Charlotte, Il ne s'agit pas d'un bug. Les rapports sont lancés chaque samedi et change de périmètre chaque trimestre. Ainsi, si le samedi n'est pas le dernier jour du trimestre, il te manque qqs journées dans le rapport. Thomas n'ayant jamais voulu priorisé la migration de ce rapport dans BI, nous le relançons manuellement à votre demande à chaque changement de trimestre pour récupérer les données manquantes. A ta disposition si tu as d'autres questions. Agathe |
| Commentaire de Dalila Belkebir [ 20/janv./09 18:20 ] |
|
Bonjour Charlotte, Les rapports ont été regénérés sur Q4 2008 (oct-nov-dec). Merci de me valider le JIRA pour clôture. cdlt, Dalila. |
| Commentaire de Charlotte Fachan [ 22/janv./09 14:30 ] |
|
Merci Dalila, c'est top. par contre je dois vérifier les données sur 2007 et il me semble que les rapports sont également cassés (Q4 2007) Merci Charlotte |
| Commentaire de Dalila Belkebir [ 22/janv./09 14:45 ] |
|
Bonjour Charlotte, Aujourd'hui la base de données sur laquelle on récupère les infos n'est pas disponible aujourd'hui. Je te récupère donc le Q4 2007 demain si la base est OK. Dalila. |
| Commentaire de Charlotte Fachan [ 26/janv./09 17:11 ] |
|
Salut Dalila, est ce que les rapports sur q4 2007 ont pu être récupéré? Merci Charlotte |
| Commentaire de Dalila Belkebir [ 26/janv./09 17:14 ] |
|
Hello Charlotte, Le serveur n'est toujours pas disponible. Pourtant je pense aux seller macro tous les jours ..... :-) Dalila. |
| Commentaire de Dalila Belkebir [ 25/févr./09 11:35 ] |
|
Les rapports seller macro ont été réédités. Les rapports vont bientôt migrer dans le BI. |
[EXP-4972] Extract jeu concours 1000Mercis Création: 01/oct./09 10:26 Mise à jour: 19/avr./10 17:08 Résolue: 10/mars/10 11:38 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Carole Visser | Attribution: | Ayoub Benseghir |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
inscrits PriceMinister_Mariage 20100126.rar
inscrits PriceMinister_Mariage non-membres 20091217.zip
inscrits_PriceMinister_Mariage_20100216.csv
Priorité Optin.xlsx
Tracking par idfrom.xlsx
|
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Nous organisons avec 1000Mercis un jeu concours « Les surprises du mariage » qui débutera le 15 octobre. Cette opération de collecte d'adresses durera environ 2 mois. Il faudrait donc prévoir 2 extracts un au milieu du jeu et un à la fin c'est-à-dire mi-novembre et mi-décembre. Voici le format de l'extract: e_mail;prenom;nom;civilite;optin A votre dispo si vous avez des questions. Merci Carole |
| Commentaires |
| Commentaire de Carole Visser [ 10/déc./09 15:44 ] |
|
Bonjour, Le premier extract pour le jeu concours "les surprises du mariage" est prévue pour jeudi prochain (17/12). Eric, est ce que c'est ok pour toi?? Carole |
| Commentaire de Carole Visser [ 19/janv./10 14:41 ] |
|
Bonjour Eric, Le jeu concours "Les surprises du mariage" se termine jeudi prochain (21/01). 1000Mercis devrait nous fournir l'extract en début de semaine. Est ce que c'est possible pour toi de l'intégrer la semaine prochaine? Merci Carole |
| Commentaire de Eric Vannier [ 19/janv./10 14:47 ] |
|
Bonjour Carole, Pas de soucis, ne vous loupez pas car je ne suis pas là , la semaine d'après .... Il faut un code de tracking pour me permettre l'intégration. Merci |
| Commentaire de Carole Visser [ 29/janv./10 10:48 ] |
|
Eric, Tu trouveras en pièces jointes un fichier .RAR contenant l'extract de l'ensemble des inscrits à l'opération « Les surprises du mariage » ainsi qu'un fichier indiquant le tracking associé à chaque idfrom. Et voici le mot de passe pour ouvrir le fichier : mm_20100126 Cet extract contient les informations suivantes pour les 316 203 inscrits avec email valide au jeu : - Prénom - Nom - Civilité - Optin - Date d'inscription au jeu - Id_from En ce qui concerne l'optin : Oui : opt in partenaires Oui mais pas partenaires : opt in Non : opt out A ta dispo si tu as des questions, Carole |
| Commentaire de Eric Vannier [ 29/janv./10 14:42 ] |
| L'import est en cours |
| Commentaire de Carole Visser [ 11/févr./10 14:56 ] |
|
Eric, Comme vu ensemble, il faudrait modifier le first tracking des individus présents dans le premier extract de l'OP de collecte. Il faudrait leur appliquer les mêmes first tracking par id from que pour le 2ème extract. Tu trouveras la table de correspondance en pièce jointe ainsi que le premier extract. A ta dispo si tu as des questions, Carole |
| Commentaire de Carole Visser [ 16/févr./10 12:37 ] |
|
Eric, Voici le mot de passe pour ouvrir le fichier premier extract : 20091218 Carole |
| Commentaire de Eric Vannier [ 18/févr./10 18:32 ] |
| Un peu de travail pour toi |
| Commentaire de Ayoub Benseghir [ 24/févr./10 10:47 ] |
| C'est fait. |
| Commentaire de Carole Visser [ 12/avr./10 12:17 ] |
|
Ayoub, Nous nous sommes aperçu avec Eric la semaine dernière qu'il y a avait eu un problème au moment de l'import des contacts de l'OP de collecte. Le batch a été stoppé et environ 150 000 personnes n'ont pas été intégrées dans la base. Comme vu avec Eric ce matin, ces contacts sont désormais dans la base PM. Il faudrait maintenant leur attribuer le bon first tracking (cf. pièces jointes). A ta dispo si tu as des questions, Merci Carole |
| Commentaire de Ayoub Benseghir [ 12/avr./10 14:11 ] |
| c'est fait. |
| Commentaire de Carole Visser [ 12/avr./10 14:14 ] |
| Merci! |
| Commentaire de Carole Visser [ 15/avr./10 17:30 ] |
|
Eric, C'est bizarre, les personnes avec le first tracking 2285844 n'apparaissent toujours dans les rapports BI sur les first tracking. Est-ce que tu as vérifié dans la base que tout était ok ? Merci Carole |
| Commentaire de Ayoub Benseghir [ 15/avr./10 17:48 ] |
|
Le first tracking 2285844 n'apparait pas dans le fichier que tu nous as fourni. A ta dispo pour en discuter. Ayoub |
| Commentaire de Ayoub Benseghir [ 15/avr./10 17:50 ] |
| On vient de comprendre.... On a mis les idfrom au lieu des first tracking (on avait raté l'épisode sur les correspondances) Je m'en occupe au plus vite |
| Commentaire de Carole Visser [ 15/avr./10 18:36 ] |
|
Tu penses que ça pourra être fait pour quand? |
| Commentaire de Ayoub Benseghir [ 16/avr./10 10:12 ] |
| Dans la matinée :) |
| Commentaire de Carole Visser [ 19/avr./10 11:51 ] |
| Est ce que c'est ok pour les tracking? |
| Commentaire de Ayoub Benseghir [ 19/avr./10 11:53 ] |
| C'est bon pour nous, qu'est ce que les rapports BI te disent? |
| Commentaire de Carole Visser [ 19/avr./10 17:08 ] |
|
C'est bon, tous les first tracking apparaissent dans les rapports BI. Merci Carole |
[BIN-645] [Sales] : Rapport par requete SQL sur ventes de lots sur Price Création: 13/janv./10 13:21 Mise à jour: 16/mars/10 17:41 Résolue: 16/mars/10 17:24 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Sales |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Gaël Seguillon | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Comme vu avec Dalila hier et dans le cadre du projet de la
mise en place de type de produits lots sur PM, je cherche à avoir des
informations sur les transactions effectuées sur ce type de produit sur
le site. La recherche doit être faite par mots clés du titre (lot ou lots) Par ailleurs si c'est possible on peut aussi récupérer les données concernant les fiches produits sur lesquelles figurent l'attribut conditionnement lot (produits concernés : timbres, cartes principalement) Dans cet extrait j'aurai besoin, un global autorisé VA/commission/nbre d'articles, fdp moyen/prix moyen article sur les 3 derniers mois et un détail des ventes avec titre, type de produit, frais de port associé à votre dispo pour plus d'infos Gaël |
| Commentaires |
| Commentaire de Cyril Tanneau [ 18/janv./10 14:25 ] |
|
Gaël, Au sujet de ta demande, je te propose que nous procédions en deux temps. Un premier lot consisterait à extraire pour les produits dont le titre contient "lot" ou "lots" les indicateurs financiers suivants: - le nombre de produits - le nombre d'articles autorisés, - Le VA , - La commission PM, - Les frais de port moyens, - le prix moyen de l'article Cet extract concerne les articles autorisés au cours des trois derniers mois et l'extract sera organisé par famille de produits. Dans un second temps, si les chiffres sortis sont concluants, nous pourrons passer à un second extract plus détaillé. Est-ce que cela te convient? J'attends ton GO pour lancer l'nanalyse. merci, Cyril |
| Commentaire de Gaël Seguillon [ 18/janv./10 19:31 ] |
|
ca me semble parfait on peut démarrer ainsi merci Cyril ! |
| Commentaire de Cyril Tanneau [ 25/janv./10 11:41 ] |
|
Gaël, nous avons généré l'extract conformément à ta demande. Tu trouveras le fichier Excel dans le répertorie suivant: T:\BI\01 - Demandes ponctuelles\05 - Études commerciaux\2010-01 Extract Gaël ventes par lot(s) - Jira bin-645 Périmètre: - L'étude porte sur les produits contenant 'lot' ou 'lots' dans le titre, exceptés les anglicismes 'a lot of' ou 'lots of'. (Pas maillot ni lotterie) - On suit les articles autorisés au cours des 3 derniers mois Indicateurs suivis: - NB_PRODUITS : Nombre distinct de produits - NB_ARTICLES : Nombre distincts d'articles autorisés - VA_TTC_AUTORISÉ : Volume d'affaires TTC autorisé avec garanties et frais de port - COMMISSION_CAPTUREE : Commission totale PM capturée (avec frais de port et garanties) - FRAIS_PORT_MOYEN: Frais de port moyens TTC payés par les PriceMembers (Somme Frais_Port / NB items) - PRIX_MOYEN_ARTICLE : Prix moyen de vente de l'article (item_cost_price) Peux-tu nous faire un retour sur la demande une fois les chiffres analysés et nous préciser s'il faut générer un lot2? Merci et bonne journée, Cyril |
| Commentaire de Gaël Seguillon [ 25/janv./10 18:18 ] |
|
j'ai vu le résultat c'est nickel merci à priori ces données sont suffisantes pas forcément besoin de lot 2 Gaël |
| Commentaire de Gaël Seguillon [ 01/févr./10 10:19 ] |
|
plus pour le suivi SAV il faudrait pouvoir obtenir les données suivantes, taux de claims sur les fiches de lots Le nombre d'annonces actives en lignes (détail par catégorie comme sur le volume vendu) comportant le mot lot, est aussi une information intéressante celà nous permet de calculer le taux de conversion de ces annonces de lot merci Gaël |
| Commentaire de Cyril Tanneau [ 04/févr./10 15:02 ] |
|
Gaël, Pas de problème quant au calcul des réclamations rapportées sur ces produits. Je créé deux colonnes, une avec le nombre total de réclamations, une autre avec le nombre de réclamations acceptées. Au sujet du nombre d'annonces actives (visibles), je ne peux que sortir le nombre d'annonces actives à ce jour, je ne peux pas remonter cette informations sur les six derniers mois car cette information n'est pas historisée dans le BI, ce qui peut fausser ton taux de conversion. Qu'en penses-tu? Merci, Cyril |
| Commentaire de Gaël Seguillon [ 04/févr./10 15:17 ] |
|
sur les annonces actives oui c'est plus un état des lieux à aujourd'hui qui'il nous faut merci Gaël |
| Commentaire de Cyril Tanneau [ 23/févr./10 17:39 ] |
|
Salut Gaël, suite aux informations supplémentaires que tu as demandé, j'ai lancé la génération d'un second extract qui permet de renseigner: - le nombre distinct de réclamations sur les articles autorisés - le nombre distinct de réclamations acceptées sur les articles autorisés - le nombre d'annonces visibles et actives associées aux fiches produits du périmètre (ventes par lots, 3 derniers mois...) --> L'étude se base sur le même périmètre que celui décrit ci-dessus. Tu trouveras le second extract dans le dossier T:\BI\01 - Demandes ponctuelles\05 - Études commerciaux\2010-01 Extract Gaël ventes par lot(s) - Jira bin-645 sous le nom V2_Extract_Ventes_par_lots.xls Pour info, l'extract date du 05/02/2010. Merci de valider la demande si cela te convient, Bonne fin de journée, Cyril |
| Commentaire de Cyril Tanneau [ 16/mars/10 17:24 ] |
|
Gaël, peux-tu valider la demande s'il te plait? merci, Cyril |
| Commentaire de Gaël Seguillon [ 16/mars/10 17:31 ] |
|
désolé en fait j'avais déjà vu le fichier mais pas mis de commentaire c'est tout bon pour moi merci Gaël |
[EXP-677] Mise à jour du KERNEL sur les différents SA 32 bits de la plateforme Création: 23/déc./05 15:28 Mise à jour: 25/juin/07 18:55 Résolue: 20/févr./06 12:05 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Evolution |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Sébastien Tournay | Attribution: | Ranto Andriambololona |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Plannifier avec JMH via différentes MAI une mise à jour du KERNEL sur les SA 32 bits en PROD. Le but est d'arriver au même niveau de kernel que sur TELLUS dans le cadre du projet BI. ATTENTION à bien plannfier les interventions et de communiquer au moment ou Jet s'apprête à rebooter les serveurs. On peut le faire en journée à condition de sortir les SA du pool. [pmas@parques priceminister]$ for i in parques esculape tellus venus hercule neptune junon; do ssh pmas@$i uname -a;done Linux parques 2.4.21-20.ELsmp #1 SMP Wed Aug 18 20:46:40 EDT 2004 i686 i686 i386 GNU/Linux Linux esculape 2.4.21-20.ELsmp #1 SMP Wed Aug 18 20:46:40 EDT 2004 i686 i686 i386 GNU/Linux Linux tellus 2.4.21-37.ELsmp #1 SMP Wed Sep 7 13:28:55 EDT 2005 i686 i686 i386 GNU/Linux Linux venus 2.4.21-20.ELsmp #1 SMP Wed Aug 18 20:46:40 EDT 2004 i686 i686 i386 GNU/Linux Linux hercule 2.4.21-20.ELsmp #1 SMP Wed Aug 18 20:46:40 EDT 2004 i686 i686 i386 GNU/Linux Linux neptune 2.4.21-20.ELsmp #1 SMP Wed Aug 18 20:46:40 EDT 2004 i686 i686 i386 GNU/Linux Linux junon 2.4.21-32.ELsmp #1 SMP Fri Apr 15 21:17:59 EDT 2005 i686 i686 i386 GNU/Linux |
| Commentaires |
| Commentaire de Ranto Andriambololona [ 04/janv./06 15:50 ] |
|
Une MEP a été ouverte chez JET (MEP-005044) dans laquelle on programme la MAJ de VENUS ce Lundi 09 janvier 2006. Il doivent m'appeller avant (cette semaine) pour bien identifier le besoin et confirmer le timing |
| Commentaire de Ranto Andriambololona [ 31/janv./06 11:24 ] |
|
Nouveau plalling proposé à JET 07/02 - Parques 14/02 - Hercule 21/02 - Junon 28/02 - Neptune 07/03 - Titan |
| Commentaire de Ranto Andriambololona [ 31/janv./06 15:20 ] |
|
Validé par JET (JL Blaise) et le bureau technique 07/02 - Hercule 14/02 - Junon |
| Commentaire de Ranto Andriambololona [ 08/févr./06 17:10 ] |
|
Nouveau planning 16/02 - Hercule 21/02 - Junon |
[APP-22596] Transformation de mémos en souhaits?! Création: 15/oct./08 14:31 Mise à jour: 13/janv./09 11:58 Résolue: 28/nov./08 14:24 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Souhaits |
| Affecte la/les version(s): | 31.0.1 |
| Version(s) corrigée(s): | 38.0.0 (TX-D Bis) |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Agathe Remy | Attribution: | Emeric Teil |
| Résolution: | Aucune correction envisagée | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Article_Memo_Dispo.jpg
Article_Memo_Plus_Dispo.jpg
|
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM: | *** RESERVE *** |
| Description |
|
Lors de la mise en place du BI Souhait, nous avons constaté
qu'il arrive qu'un mémo puisse être transformé en souhait
(wsh_type_code=30 => 10) , ce qui ne semble correspondre à aucune
règle de gestion. Cela correspond à un évènement « UPDATE »
(wse_type_code=20). Cela nous pose un problème pour nos dénormalisations, notamment le calcul de la date de 1er dépôt d'un souhait qui peut donc varier... Nous aurions donc besoin de comprendre comment et pourquoi cela peut arriver. Voici un exemple identifié grâce au décalage entre l'Integ et la Prod : Intég : wish_id;buyer_account_id;product_id;creation_date;change_date;wsh_status_code;wsh_type_code;last_mail_date;is_removed_after_buy;buy_price;currency_id;adv_quality_code;seller_score;prd_type_code;prd_medium_code;prd_line_key;prd_model_key;selection_date;advert_id;complement_product_id;row_version 19703780;2929071;4709600;16/05/2008 11:08:06;16/05/2008 11:08:06;10;30;;1;;978;;;1140;;;;16/05/2008 10:37:29;;;1 Prod : wish_id;buyer_account_id;product_id;creation_date;change_date;wsh_status_code;wsh_type_code;last_mail_date;is_removed_after_buy;buy_price;currency_id;adv_quality_code;seller_score;prd_type_code;prd_medium_code;prd_line_key;prd_model_key;selection_date;advert_id;complement_product_id;row_version 19703780;2929071;4709600;16/05/2008 11:08:06;18/09/2008 11:38:05;10;10;11/09/2008 11:38:05;1;130;978;;;1140;;;;16/05/2008 10:37:29;;;2 Merci. Agathe |
| Commentaires |
| Commentaire de Emeric Teil [ 20/oct./08 16:07 ] |
|
Il est fonctionnellement voulu qu'un article mémorisé puisse
devenir un souhait : dans le cas où l'article n'est plus disponible, on
propose alors à l'utilisateur de transformer son article mémorisé en
souhait. C'est ce qui ce passe dans l'exemple fourni. cf capture d'écran |
[EXP-882] Mise à jour du DNS interne Création: 13/janv./06 16:09 Mise à jour: 25/juin/07 18:55 Echéance: 16/janv./06 00:00 Résolue: 16/janv./06 14:39 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Evolution |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Sébastien Tournay | Attribution: | Pap Ndiaye |
| Résolution: | Corrigé | ||
| Estimation restante: | 0 minutes | ||
| Temps consacré: | 1 heure | ||
| Estimation originale: | 1 heure | ||
| Description |
|
On a besoin pour différentes taches (FAST, BI, exploit via
ARKOON) de renseigner au niveau de notre DNS interne le nom des serveurs
de production avec leur adresse privée sur le réseau JMH. au même titre que nous avons fastadmin.jmh.lan > 10.150.28.78, il nous faut cela pour tous les serveurs de prod Il faudrait donc ajouter dans notre zone amphitrite.jmh.lan=amphitrite=10.150.28.83 terra.jmh.lan=terra=10.150.28.82 sol.jmh.lan=sol=10.150.28.81 esculape.jmh.lan=esculape=10.150.28.67 mercure.jmh.lan=mercure=10.150.28.69 venus.jmh.lan=venus=10.150.28.70 tellus.jmh.lan=tellus=10.150.28.73 saturne.jmh.lan=saturne=10.150.28.68 parques.jmh.lan=parques=10.150.28.75 titan.jmh.lan=titan=10.150.28.80 jupiter.jmh.lan=jupiter=10.150.28.76 hercule.jmh.lan=hercule=10.150.28.77 neptune.jmh.lan=neptune=10.150.28.78=fastadmin.jmh.lan junon.jmh.lan=junon=10.150.28.74 angita.jmh.lan=angita=10.150.28.84 aurore.jmh.lan=aurore=10.150.28.85 orcus.jmh.lan=orcus=10.150.28.87 janus.jmh.lan=janus=10.150.28.77.89 latone.jmh.lan=latone=10.150.28.88 cupidon.jmh.lan=cupidon=10.150.28.65 phaeton.jmh.lan=phaeton=10.150.28.72 graces.jmh.lan=graces=10.150.28.71 bacchus.jmh.lan=bacchus=10.150.28.79 |
[IMP-2665] création profil d'import avec création/maj annonces et création produit pour le partenaire ajmtrader Création: 01/oct./08 17:26 Mise à jour: 30/oct./09 15:50 Résolue: 09/oct./08 10:47 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Robin Dohin | Attribution: | Fotigui Tangara |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
errors_newinventory_ajmtrader.txt
inventory_ajmtrader.txt
mapping_ajmtrader.xls
monsoon-inventory 29-09a.txt
newinventory_ajmtrader.txt
|
| Pays: |
FRA - France
|
| Login: | ajmtrader |
| Séparateur: | Tabulation |
| Type de traitement: |
Mise à jour/création annonces avec création produits (écrasement)
|
| Description |
|
création profil d'import avec création/maj annonces et création produit pour le partenaire ajmtrader fichier au format du pro colonne A : ne pas importer colonne B : référence vendeur 1 colonne C : référence vendeur 2 colonne D : code ASIN à importer en tant qu'ID produit (utile pour les futurs imports) colonne E : code ISBN colonne F : ne pas importer colonne G : ne pas importer colonne H : titre colonne I : quantité colonne J : état (cf mapping) colonne K : prix en livres sterling (multiplier par 1.273 pour avoir le prix en euros) colonne L : Collection ("True" = C) colonne M : ne pas importer colonne N : commentaire annonce (supprimer la mention"box + xx" en fin de cellule) / commentaire privé : "box + xx" en fin de cellule colonne O : ne pas importer colonne P : ne pas importer colonne Q : ne pas importer colonne R : ne pas importer colonne S : ne pas importer colonne T : ne pas importer colonne U : ne pas importer colonne V : ne pas importer colonne W : ne pas importer colonne X : ne pas importer colonne Y : ne pas importer colonne Z : ne pas importer colonne AA: ne pas importer colonne AB: ne pas importer colonne AC: ne pas importer colonne AD: ne pas importer colonne AE: auteur colonne AF: Format (cf mapping) colonne AG: ne pas importer colonne AH: code EAN colonne AI: ne pas importer colonne AJ: épaisseur en centimètres colonne AK: ne pas importer colonne AL: ne pas importer colonne AM: ne pas importer colonne AN: ne pas importer colonne AO: ne pas importer colonne AP: ne pas importer colonne AQ: ne pas importer colonne AR: ne pas importer colonne AS: ne pas importer colonne AT: ne pas importer colonne AU: ne pas importer colonne AV: ne pas importer colonne AW: Longueur (en centimètres) colonne AX: ne pas importer colonne AY: ne pas importer colonne AZ: Nombre de pages colonne BA: Date de publication : deux modèles de dates (AAAA-MM et JJ/MM/AAAA) colonne BB: Editeur colonne BC: ne pas importer colonne BD: ne pas importer colonne BE: ne pas importer colonne BF: ne pas importer colonne BG: ne pas importer colonne BH: ne pas importer colonne BI: ne pas importer colonne BJ: ne pas importer colonne BK: ne pas importer colonne BL: ne pas importer colonne BM: ne pas importer colonne BN: poids (en kilogrammes) colonne BO: Largeur (en centimètres) Classification par défaut pour la création de fiches produits : Classification Decitre 1: littérature étrangère Classification Decitre 2 : littérature anglo-saxonne Classification Decitre 3 : littérature anglo-saxonne |
| Commentaires |
| Commentaire de Robin Dohin [ 01/oct./08 17:26 ] |
| fichier du pro |
| Commentaire de Robin Dohin [ 01/oct./08 17:27 ] |
| mapping état/format |
| Commentaire de Fotigui Tangara [ 03/oct./08 10:14 ] |
| Demande en cours... |
| Commentaire de Fotigui Tangara [ 03/oct./08 14:59 ] |
|
Les outils d'import, en terme de nombre de colonnes sont
limités à 50 colonnes. Le fichier du pro présente 66 colonnes. Données importante au-delà de la 50ème colonne : - Date de parution - Editeur - Nombre de pages. Dans un premier temps j'ai passé le fichier en Mise à jour/création annonces. |
| Commentaire de Fotigui Tangara [ 06/oct./08 13:30 ] |
| Souhaitez-vous une réorganisation des colonnes du fichier ? Cela nous permettra de pouvoir créer des produits et annonces associées. |
| Commentaire de Fotigui Tangara [ 06/oct./08 13:56 ] |
|
Vu avec Robin : Il prendra contact avec le PRO en vue d'apporter une modification au fichier de ce dernier. Je ferme la demande d'ici là. Elle pourra être réouvert pour une éventuelle création de produits et annonces associées. |
| Commentaire de Robin Dohin [ 06/oct./08 14:21 ] |
|
Vu avec le pro : il utilisera dorénavant ce format de fichier avec un nombre de colonnes réduit : ci-joint le nouveau fichier du pro colonne A : ne pas importer colonne B : référence vendeur 1 colonne C : référence vendeur 2 colonne D : code ASIN à importer en tant qu'ID produit (utile pour les futurs imports) colonne E : code ISBN colonne F : ne pas importer colonne G : ne pas importer colonne H : titre colonne I : quantité colonne J : état (cf mapping) colonne K : prix en livres sterling (multiplier par 1.273 pour avoir le prix en euros) colonne L : Collection ("True" = C) colonne M : ne pas importer colonne N : commentaire annonce (supprimer la mention"box + xx" en fin de cellule) / commentaire privé : "box + xx" en fin de cellule colonne O : ne pas importer colonne P : ne pas importer colonne Q : ne pas importer colonne R : ne pas importer colonne S : ne pas importer colonne T : ne pas importer colonne U : ne pas importer colonne V : ne pas importer colonne W : ne pas importer colonne X : ne pas importer colonne Y : ne pas importer colonne Z : ne pas importer colonne AA: ne pas importer colonne AB: ne pas importer colonne AC: ne pas importer colonne AD: ne pas importer colonne AE: auteur colonne AF: Format (cf mapping) colonne AG: ne pas importer colonne AH: code EAN colonne AI: ne pas importer colonne AJ: épaisseur en centimètres colonne AK: ne pas importer colonne AL: Longueur (en centimètres) colonne AM: ne pas importer colonne AN: ne pas importer colonne AO: Nombre de pages colonne AP: Date de publication : deux modèles de dates (AAAA-MM et JJ/MM/AAAA) colonne AQ: Editeur colonne AR: poids (en kilogrammes) colonne AS: Largeur (en centimètres) |
| Commentaire de Robin Dohin [ 06/oct./08 14:21 ] |
| nouveau fichier du partenaire ajmtrader |
| Commentaire de Fotigui Tangara [ 06/oct./08 15:32 ] |
|
Excel a "massacré" les EAN :-) !!!! |
| Commentaire de Robin Dohin [ 06/oct./08 16:15 ] |
| Les EAN ont été modifiés et "démassacrés"... |
| Commentaire de Robin Dohin [ 06/oct./08 16:15 ] |
| un nouveau fichier a été joint avec les EAN modifiés |
| Commentaire de Fotigui Tangara [ 07/oct./08 15:54 ] |
| Le fichier passe à 57%, je te mets le fichier d'erreurs. |
| Commentaire de Fotigui Tangara [ 07/oct./08 15:54 ] |
| Le fichier passe à 57%, je te mets le fichier d'erreurs en PJ. |
| Commentaire de Robin Dohin [ 08/oct./08 14:38 ] |
|
Vu avec le pro : est-il possible d'augmenter les prix lorsque ceux-ci sont trop bas pour qu'ils atteignent le minimum de 0.90 ¿? |
| Commentaire de Robin Dohin [ 08/oct./08 16:14 ] |
| le partenaire a finalement augmenté lui même ses prix. merci de ne pas tenir compte du commentaire précédent. |
[IMP-3044] création profil d'import avec création/maj annonces et création produit pour le partenaire ajmtraderuk Création: 06/janv./09 10:30 Mise à jour: 30/oct./09 15:52 Résolue: 20/janv./09 11:51 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Jeremy Pallot | Attribution: | Daniel Pintamalli |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
pmuk-monsoon export 05-01.txt
|
| Pays: |
GBR - Royaume Uni
|
| Login: | ajmtraderuk |
| Séparateur: | Tabulation |
| Type de traitement: |
Mise à jour/création annonces avec création produits (écrasement)
|
| Description |
|
création profil d'import avec création/maj annonces et création produit pour le partenaire ajmtrader fichier au format du pro colonne A : ne pas importer colonne B : référence vendeur 1 colonne C : référence vendeur 2 colonne D : code ASIN à importer en tant qu'ID produit (utile pour les futurs imports) colonne E : code ISBN colonne F : ne pas importer colonne G : ne pas importer colonne H : titre colonne I : quantité colonne J : état (cf mapping) colonne K : prix en livres sterling (multiplier par 1.273 pour avoir le prix en euros) colonne L : Collection ("True" = C) colonne M : ne pas importer colonne N : commentaire annonce (supprimer la mention"box + xx" en fin de cellule) / commentaire privé : "box + xx" en fin de cellule colonne O : ne pas importer colonne P : ne pas importer colonne Q : ne pas importer colonne R : ne pas importer colonne S : ne pas importer colonne T : ne pas importer colonne U : ne pas importer colonne V : ne pas importer colonne W : ne pas importer colonne X : ne pas importer colonne Y : ne pas importer colonne Z : ne pas importer colonne AA: ne pas importer colonne AB: ne pas importer colonne AC: ne pas importer colonne AD: ne pas importer colonne AE: auteur colonne AF: Format (cf mapping) colonne AG: ne pas importer colonne AH: code EAN colonne AI: ne pas importer colonne AJ: épaisseur en centimètres colonne AK: ne pas importer colonne AL: ne pas importer colonne AM: ne pas importer colonne AN: ne pas importer colonne AO: ne pas importer colonne AP: ne pas importer colonne AQ: ne pas importer colonne AR: ne pas importer colonne AS: ne pas importer colonne AT: ne pas importer colonne AU: ne pas importer colonne AV: ne pas importer colonne AW: Longueur (en centimètres) colonne AX: ne pas importer colonne AY: ne pas importer colonne AZ: Nombre de pages colonne BA: Date de publication : deux modèles de dates (AAAA-MM et JJ/MM/AAAA) colonne BB: Editeur colonne BC: ne pas importer colonne BD: ne pas importer colonne BE: ne pas importer colonne BF: ne pas importer colonne BG: ne pas importer colonne BH: ne pas importer colonne BI: ne pas importer colonne BJ: ne pas importer colonne BK: ne pas importer colonne BL: ne pas importer colonne BM: ne pas importer colonne BN: poids (en kilogrammes) colonne BO: Largeur (en centimètres) Attention création de produit pour les articles qui ne possédent pas de ISBN |
| Commentaires |
| Commentaire de Jeremy Pallot [ 19/janv./09 13:29 ] |
| Ne pas multiplier le prix par 1.27, il mettre en ligne des prix en £ avec frais de port. |
| Commentaire de Daniel Pintamalli [ 20/janv./09 11:00 ] |
|
Import en cours. Le traitement est en 'mise à jour/création d'annonces' car les classifications thématiques ne sont pas exploitables. http://bouk.priceminister.jmh/datafile_back?action=advfilesearch&file_id=5956449&login=&process_code=&status=&use_proc_date=false&start_date=20%2F01%2F2009&end_date=20%2F01%2F2009&order=&x=0&y=0 |
| Commentaire de Daniel Pintamalli [ 20/janv./09 11:50 ] |
|
Le fichier passe à 66%. Rapport d'erreurs: No product could be found with this reference number. => 1788 lignes The 'Condition [cell 50299]' column is compulsory => 10 lignes The price for this item cannot exceed £XX.XX. => 795 lignes The 'Quantity [cell 50300]' column is compulsory => 34 lignes You cannot create a listing with a quanitity of 0. => 27 lignes |
[APP-10462] Pb de déploiement sur les pages pseudo-statiques Création: 13/juin/06 15:13 Mise à jour: 25/juin/07 18:40 Résolue: 13/juin/06 15:34 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Infrastructure |
| Affecte la/les version(s): | 9.0.0.1 |
| Version(s) corrigée(s): | 9.0.0.1 |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Christophe Garcia | Attribution: | Pap Ndiaye |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
[adminpm@deutz conf]$ pmapacheconfswitch Switching configuration file /etc/init.d/httpd restart: httpd restarted Apache is now running with the production configuration. Updating static pages...Starting with sleeptime = 0 www.pm.lan:www:..mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-www/auto-moto.newtemp': Aucun fichier ou répertoire de ce type .............. done voiture.pm.lan:voiture:................ done virginmega.pm.lan:virginmega:................ done tiscalibe.pm.lan:tiscalibe:................ done test.pm.lan:test:................ done rueducommerce.pm.lan:rueducommerce:................ done rfm.pm.lan:rfm:................ done preview.pm.lan:preview:................ done presencepc.pm.lan:presencepc:................ done pcdirect.pm.lan:pcdirect:................ done ofup.pm.lan:ofup:................ done mobilokaz.pm.lan:mobilokaz:................ done mobilesachat.pm.lan:mobilesachat:................ done m6.pm.lan:m6:................ done m6net.pm.lan:m6net:................ done m6music.pm.lan:m6music:................ done m6game.pm.lan:m6game:................ done liberation.pm.lan:liberation:.. done koobuycity.pm.lan:koobuycity:................ done jeuxvideo.pm.lan:jeuxvideo:................ done freesurf.pm.lan:freesurf:................ done francemobiles.pm.lan:francemobiles:................ done europe2.pm.lan:europe2:................ done epik.pm.lan:epik:................ done eglue.pm.lan:eglue:................ done croix-rouge.pm.lan:croix-rouge:................ done cinenow.pm.lan:cinenow:................ done camif.pm.lan:camif:................ done bo.pm.lan:bo:................ done bi.pm.lan:bi:................ done bambinoccasion.pm.lan:bambinoccasion:................ done akamai.pm.lan:akamai:../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/accueil.newtemp: Aucun fichier ou répertoire de ce type mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/accueil.newtemp': Aucun fichier ou répertoire de ce type ../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/auto-moto.newtemp: Aucun fichier ou répertoire de ce type mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/auto-moto.newtemp': Aucun fichier ou répertoire de ce type ../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/livres-bd.newtemp: Aucun fichier ou répertoire de ce type mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/livres-bd.newtemp': Aucun fichier ou répertoire de ce type ../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/musique-cd.newtemp: Aucun fichier ou répertoire de ce type mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/musique-cd.newtemp': Aucun fichier ou répertoire de ce type ../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/video-dvd-vhs.newtemp: Aucun fichier ou répertoire de ce type mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/video-dvd-vhs.newtemp': Aucun fichier ou répertoire de ce type ../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/jeux-video.newtemp: Aucun fichier ou répertoire de ce type mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/jeux-video.newtemp': Aucun fichier ou répertoire de ce type ../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/telephone-pda.newtemp: Aucun fichier ou répertoire de ce type mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/telephone-pda.newtemp': Aucun fichier ou répertoire de ce type ../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/informatique-logiciels.newtemp: Aucun fichier ou répertoire de ce type mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/informatique-logiciels.newtemp': Aucun fichier ou répertoire de ce type ../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/image-son.newtemp: Aucun fichier ou répertoire de ce type mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/image-son.newtemp': Aucun fichier ou répertoire de ce type ../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/voyages.newtemp: Aucun fichier ou répertoire de ce type mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/voyages.newtemp': Aucun fichier ou répertoire de ce type ../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/bargain.newtemp: Aucun fichier ou répertoire de ce type mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/bargain.newtemp': Aucun fichier ou répertoire de ce type ../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/electromenager.newtemp: Aucun fichier ou répertoire de ce type mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/electromenager.newtemp': Aucun fichier ou répertoire de ce type ../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/enfants-jeux-jouets.newtemp: Aucun fichier ou répertoire de ce type mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/enfants-jeux-jouets.newtemp': Aucun fichier ou répertoire de ce type ../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/mode-textile.newtemp: Aucun fichier ou répertoire de ce type mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/mode-textile.newtemp': Aucun fichier ou répertoire de ce type ../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/vins-saveurs.newtemp: Aucun fichier ou répertoire de ce type mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/vins-saveurs.newtemp': Aucun fichier ou répertoire de ce type ../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/loisirs-sports.newtemp: Aucun fichier ou répertoire de ce type mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/loisirs-sports.newtemp': Aucun fichier ou répertoire de ce type done acf.pm.lan:acf:................ done |
[APP-15131] [CoSAV] Conservation des 6 premiers chiffres de la cb Création: 15/févr./07 18:22 Mise à jour: 20/févr./09 15:53 Résolue: 05/févr./09 10:03 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Paiement |
| Affecte la/les version(s): | 12.0.2 |
| Version(s) corrigée(s): | 41.0.0 (TX-E) |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Steven Harel | Attribution: | Fabien Bourdoulous |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Pays: |
ALL - Tous
|
||||||||
| Site: | Prod | ||||||||
| Projets PM: | *** RESERVE *** | ||||||||
| Classif1: | TX | ||||||||
| Classif2: | paiement | ||||||||
| Classif FONC: | CoSAV | ||||||||
| Description |
|
l'apparition des ecb a provoqué une grosse faille dans l'utilisation des coupons actuellement, nous validons les paniers avec coupon 1er achat et coupon parrainage filleul uniquement si le numéro de carte n'a pas été utilisé par le passé cependant, les numéros de ecb sont uniques et donc jamais utilisées par le passé une personne peut donc utiliser autant de coupon qu'elle a de ecb il suffit qu'elle crée autant de comptes sauf si les plages de ecb sont renseignées dans le système par l'exploit le problème est qu'on n'a pu se procurer qu'une partie des plages il y a bcp de fraude sur les plages qui nous manquent le dernier qu'on a attrapé avait utilisé pour 15000 euros de coupons l'idée est de constituer nous-même nos plages de ecb les plages de ecb sont définies par les 6 premiers chiffres et actuellement nous ne conservons que les 4 premiers si nous conservons les 6 premiers chiffres nous pourrons alors demander un rapport : - des 6 premiers chiffres de la carte bancaire, - pour les transactions pour lesquelles l'acheteur a déclaré avoir utilisé une ecb. et identifier ainsi les plages de ecb et mettre à jour le système régulierement |
| Commentaires |
| Commentaire de Sébastien Aubert [ 27/juin/07 17:43 ] |
|
Aucun soucis légal, vu avec Benoit Tabaka. L'objectif est donc de récupérer, au lieu des 4 premiers et 2 derniers chiffre de la CB, les 6 premiers et toujours les 2 derniers. |
| Commentaire de Arnaud Forgues [ 28/juin/07 19:02 ] |
|
il serait pas mal de faire une petite analyse des impacts
potentiels d'une telle modif. Par exemple le fait que tous les mots
clefs qui se servent actuellement du champs "$purchase.CardNumberBegin"
seront éventuellement buggés si ils sont exploité de la manière suivante
: "$purchase.CardNumberBegin == "0000"". Il faudra remplacer le mot
clef par "$purchase.CardNumberBegin.startsWith("0000")" Il faudra également modifier l'écran BO panier qui affiche ces informations là. Et sinon il faudra s'assurer qu'on n'a pas d'impact sur le paiement par 1euro.com qui se sert aujourd'hui de ce champs pour stocker les 4 premiers chiffres du numero de compte 1euro des utilisateurs payant par ce moyen de paiement. Voilou pour quelques idées qui me viennent là comme ça mais il y a peut etre d'autres ... |
| Commentaire de Cedric Favero [ 25/sept./07 14:56 ] |
|
Les fraudes ont un besoin assez important de cette
affichage des 6 premiers numéros de carte afin de constituer un fichier
de plages ECB et pouvoir les enregistrer en dur dans le système en les
transmettant à l'exploit (cf JIRA lié). Est-il envisageable de pousser un peu cette demande qui est réelement critique pour la prévention des fraudes aux coupons? |
| Commentaire de Steven Harel [ 25/sept./07 15:40 ] |
|
c'est vraiment critique, j'aimerais vraiment qu'on avance sur cette demande sans cette info, on est incapables de faire face aux fraudes massives aux coupons pour les banques françaises ET pour les banques européennes et une fraude massive c'est plusieurs milliers d'euros (15.000 pour le plus gros cas) soit une partie significative du budget coupons du marketing |
| Commentaire de Benoit Tabaka [ 19/déc./08 16:57 ] |
|
Comme le sujet est revenu récemment suite à plusieurs
fraudes, il faudra sans doute voir pour pousser un peu la demande. Comme je l'avais dit à Sébastien, il n'y a pas de pb légal à avoir une conservation des 6 + 2 chiffres de la CB (car ça fait ensuite 1 chance sur 1 milliard de recomposer le bon numéro de CB !). |
| Commentaire de Emeric Teil [ 19/déc./08 17:46 ] |
| OK, donc à prioriser en regard des autres demandes CoSAV. |
| Commentaire de Emeric Teil [ 02/févr./09 18:42 ] |
| Comme vu ensemble, faire au préalable une analyse technique des impacts... |
| Commentaire de Cedric Favero [ 03/févr./09 10:28 ] |
|
Petit élément supplementaire, au délà de l'affichage en BO,
saura-t-on avoir accès à ce 5e et 6 chiffre dans le BI ? Et si oui est-ce que ce sera rétroactif? (en clair est-ce que les infos ont toujours "été là" et seulement masquées?). Merci. |
| Commentaire de Arnaud Forgues [ 03/févr./09 11:22 ] |
|
On saura effectivement avoir accès à ces 5e et 6e chiffres
dans le BI comme dans les mots clefs en velocity. D'ailleurs, comme
évoqué dans un commentaire précédent, on mettra sans doute à disposition
deux méthodes afin de rester rétrocomptaible avec l'existant en terme
de mots clefs velocity : - 1 méthode qui renvoie les 4 premiers chiffres (avec le même nom qu'avant pour la rétrocomptaibilité) - 1 méthode qui renvoie les 6 premiers chiffres (avec un nouveau nom) Par contre, ce ne sera malheureusement pas rétroactif : les infos n'ont jamais été sotckés et masqués mais réellement filtrées. |
| Commentaire de Cedric Favero [ 03/févr./09 12:09 ] |
|
>Par contre, ce ne sera malheureusement pas rétroactif :
les infos n'ont jamais été sotckés et masqués mais réellement filtrées. Ok c'était le sens de ma question. Dommage. Ok pour les mots clés mais pourquoi une rétrocompatibilité? Les mots-clés ne s'appliquent que sur les nouveaux paniers... M'enfin mieux vaut trop que pas assez. |
| Commentaire de Fabien Bourdoulous [ 05/févr./09 10:02 ] |
|
Il y a maintenant 6 mots clefs velocity pour prendre en compte les 5e et 6e chiffres : carte exotique - 0000/4505 > 80 euros carte exotique - 4507/5134 > 80 euros carte exotique - 5139/9999 > 80 euros carte exotique - 000000/450599 > 80 euros carte exotique - 450700/513499 > 80 euros carte exotique - 513900/999999 > 80 euros |
| Commentaire de Cedric Favero [ 05/févr./09 10:03 ] |
|
Tu les as modifiés directement? En prod? En général c'est moi qui gère les mots clés. |
| Commentaire de Fabien Bourdoulous [ 05/févr./09 10:10 ] |
| En fait il s'agit des exemples réalisés en dev. |
| Commentaire de Fabien Bourdoulous [ 05/févr./09 10:56 ] |
|
OK, c'est mis en place. Dans les objets "PurchaseFormat.java" utilisés dans les contextes Velocity, en particulier pour les mots clefs (de type Confirmation Panier), 2 changements : $purchase.CardNumberBegin ==> pour la rétrocompatibilité, renvoie toujours seulement les 4 premiers chiffres de la CB $purchase.CardNumberBegin6 ==> renvoie les 6 premiers chiffres de la CB Pareil pour les méthodes qui renvoient les valeurs (pour les test numériques) $purchase.CardNumberBeginValue $purchase.CardNumberBeginValue6 Pour info : 1 script dans le répertoire TX-E : VTX-E_APP_15131_ALL_01_purchase_modify_col.sql 1 commit : revno: 24757 committer: fabien.bourdoulous <fabien.bourdoulous@priceminister.com> branch nick: tx timestamp: Wed 2009-02-04 18:59:38 +0100 message: modified: source/etc/jdbc.properties source/etc/priceminister-infra.properties source/generated/build/generate.properties source/src/com/babelstore/purchase/PurchaseFormat.java source/src/com/babelstore/purchase/PurchaseInfo.java source/src/com/babelstore/purchase/business/PurchaseBusinessBean.java |
| Commentaire de Cedric Favero [ 05/févr./09 17:20 ] |
|
Ok donc les mots clés sont "doublés".? Est-il nécessaire de garder les anciens si tous les nouveaux paniers font figurer les 6 chiffres? |
| Commentaire de Arnaud Forgues [ 05/févr./09 18:01 ] |
|
Pour faire le test en DEV, on a en effet doublés les mot
clés. Mais c'est toi qui vois ce que tu veux faire. A terme on peut en
effet imaginer qu'on n'aura plus besoin de la méthode
"$purchase.CardNumberBegin" (avec uniquement 4 chiffres) En gros, c'est principalement pour gérer la période de transition que l'on a mis à disposition les 2 méthodes, le temps que tu migres tu les mots clefs qui utilise cette méthode. |
| Commentaire de Cedric Favero [ 05/févr./09 18:06 ] |
| Ok parfait. Merci. |
| Commentaire de Sebastien Bruzzone [ 13/févr./09 15:27 ] |
| ok c'est bon pour moi, tout semble marcher |
Migration du mécanisme d'import des fichiers de Phaeton vers Bacchus
(EXP-2759)
|
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Evolution |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | Patrice Boulanger | Attribution: | Eric Vannier |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Config_import1_es.xml
tests.zip
|
| Pays: |
ALL - Tous
|
| Description |
|
Merci de noter ici l'ensemble des tests qui ont été et qui
seront réalisés afin de valider le bon fonctionnement du nouveau
ftpSwitch sur Bacchus.
|
| Commentaires |
| Commentaire de Eric Vannier [ 02/oct./06 10:31 ] |
|
Les différents tests pour valider le fonctionnement de ftpSwitch : 1°) On post 4 fichiers sur un compte ftp au format compressé gz , tar.gz, Zip et non compressé 2°) On crée un fichier de Config pour que les fichier soient décompressés (Filtre Expand) 3°) On déplace les fichiers vers un autre répertoire (Filtre Move) 4°) On fait une comparaison entre deux fichiers avec une différence d'une ligne par ex. (Filtre Diif) 5°) On crée un fichier qui extrait deux trois champs d'un fichier source pour le mettre dans un autre (Filtre ExtraitData) 6°) On crée un fichier à partir de quelques champs d'un fichier source (FileFromData) |
| Commentaire de Daniel Pintamalli [ 04/oct./06 11:13 ] |
| Tests en cours. |
| Commentaire de Daniel Pintamalli [ 04/oct./06 18:47 ] |
|
Test OK. En PJ les résultats correspondant à chaque test. |
| Commentaire de Eric Vannier [ 06/oct./06 17:13 ] |
| On a validé le fonctionnement de ftpSwitch et de ses divers filtres |
| Commentaire de Eric Vannier [ 06/oct./06 17:16 ] |
|
On doit encore valider malgré que ce sont ceux qui tournent sur Hercule : le seul changement ce sont des variables d'environnements (base, serveur, login, pays) ftpCompute_ng.sh import_ng_sh import_images.pl |
| Commentaire de Eric Vannier [ 06/oct./06 17:17 ] |
| Actuellement, on est bloqué par des clés ssh dans le sens Esculape vers Bacchus , ça fonctionne dans l'autre sens. |
| Commentaire de Eric Vannier [ 09/oct./06 14:48 ] |
|
Le problème de clés ssh a été résolu, maintenant on attend la résolution du soucis de modules perl pour oracle 10. La synchronisation des comptes ftp sur Bacchus et Phaeton et des répertoires pmftpstock a été effectué. |
| Commentaire de Eric Vannier [ 11/oct./06 18:51 ] |
|
Le soucis des modules perl sur esculape a été résolu. ftpCompute_ng.pl a déplacé les fichiers des divers tests précédents. import_ng.sh ne fonctionne pas car , il faut initialiser les "jndi.properties" d'après le jira Quelqu'un pourrait m'aider sur ce pb ? |
| Commentaire de Patrice Boulanger [ 12/oct./06 09:58 ] |
|
Judd, Peux tu nous renseigner là dessus? |
| Commentaire de Eric Vannier [ 12/oct./06 10:31 ] |
|
[pmas@esculape advert_import_script]$ ./import_ng.sh -d --env PROD_ES On lance importe avec les paramètres suivants : --mode FTP --in ../advert_import_readyforprocessing --filename 10802793_stock_4028937_priceminister-vivos.txt.pm --out /data/priceminister/upload/es/advert_import_work/2006-10-12_10-28-52 --sqlloader /appli/oracle/product/10.2.0/db_1/bin/sqlldr --sqlconnect babel_1/babel_1@OLTPES --java /appli/priceminister/jdk/bin/java --cp /data/priceminister/batch:/data/priceminister/client/pm-main-client.jar:/data/priceminister/client/pm-batch.jar:/appli/priceminister/jboss/client/avalon-framework.jar:/appli/priceminister/jboss/client/jbosscx-client.jar:/appli/priceminister/jboss/client/commons-logging.jar:/appli/priceminister/jboss/client/log4j.jar:/appli/priceminister/jboss/client/jmx-client.jar:/appli/priceminister/jboss/client/jboss-aspect-library-jdk50.jar:/appli/priceminister/jboss/client/jnp-client.jar:/appli/priceminister/jboss/client/scout.jar:/appli/priceminister/jboss/client/jboss-ws4ee-client.jar:/appli/priceminister/jboss/client/hibernate-annotations.jar:/appli/priceminister/jboss/client/jboss-deployment.jar:/appli/priceminister/jboss/client/jboss-transaction-client.jar:/appli/priceminister/jboss/client/jbossjmx-ant.jar:/appli/priceminister/jboss/client/jbossall-client.jar:/appli/priceminister/jboss/client/ejb3-persistence.jar:/appli/priceminister/jboss/client/activation.jar:/appli/priceminister/jboss/client/jacorb.jar:/appli/priceminister/jboss/client/concurrent.jar:/appli/priceminister/jboss/client/jboss-common-client.jar:/appli/priceminister/jboss/client/jboss-jaxrpc.jar:/appli/priceminister/jboss/client/hibernate3.jar:/appli/priceminister/jboss/client/logkit.jar:/appli/priceminister/jboss/client/cglib-2.1.jar:/appli/priceminister/jboss/client/velocity-dep-1.4.jar:/appli/priceminister/jboss/client/mail.jar:/appli/priceminister/jboss/client/jbossha-client.jar:/appli/priceminister/jboss/client/jboss-aop-jdk50.jar:/appli/priceminister/jboss/client/jboss-ejb3.jar:/appli/priceminister/jboss/client/jboss-saaj.jar:/appli/priceminister/jboss/client/namespace.jar:/appli/priceminister/jboss/client/jboss-juddiaxis.jar:/appli/priceminister/jboss/client/commons-discovery.jar:/appli/priceminister/jboss/client/jboss-iiop-client.jar:/appli/priceminister/jboss/client/getopt.jar:/appli/priceminister/jboss/client/jbosssx-client.jar:/appli/priceminister/jboss/client/jmx-invoker-adaptor-client.jar:/appli/priceminister/jboss/client/wsdl4j.jar:/appli/priceminister/jboss/client/jboss-system-client.jar:/appli/priceminister/jboss/client/jbossmq-client.jar:/appli/priceminister/jboss/client/jboss-client.jar:/appli/priceminister/jboss/client/asm.jar:/appli/priceminister/jboss/client/jboss-j2ee.jar:/appli/priceminister/jboss/client/jboss-jsr77-client.jar:/appli/priceminister/jboss/client/axis-ws4ee.jar --userid 10802793 --profileid 4028937 --originalfile priceminister-vivos.txt.pm ./import.pl --mode FTP --in ../advert_import_readyforprocessing --filename 10802793_stock_4028937_priceminister-vivos.txt.pm --out /data/priceminister/upload/es/advert_import_work/2006-10-12_10-28-52 --sqlloader /appli/oracle/product/10.2.0/db_1/bin/sqlldr --sqlconnect babel_1/babel_1@OLTPES --java /appli/priceminister/jdk/bin/java --cp /data/priceminister/batch:/data/priceminister/client/pm-main-client.jar:/data/priceminister/client/pm-batch.jar:/appli/priceminister/jboss/client/avalon-framework.jar:/appli/priceminister/jboss/client/jbosscx-client.jar:/appli/priceminister/jboss/client/commons-logging.jar:/appli/priceminister/jboss/client/log4j.jar:/appli/priceminister/jboss/client/jmx-client.jar:/appli/priceminister/jboss/client/jboss-aspect-library-jdk50.jar:/appli/priceminister/jboss/client/jnp-client.jar:/appli/priceminister/jboss/client/scout.jar:/appli/priceminister/jboss/client/jboss-ws4ee-client.jar:/appli/priceminister/jboss/client/hibernate-annotations.jar:/appli/priceminister/jboss/client/jboss-deployment.jar:/appli/priceminister/jboss/client/jboss-transaction-client.jar:/appli/priceminister/jboss/client/jbossjmx-ant.jar:/appli/priceminister/jboss/client/jbossall-client.jar:/appli/priceminister/jboss/client/ejb3-persistence.jar:/appli/priceminister/jboss/client/activation.jar:/appli/priceminister/jboss/client/jacorb.jar:/appli/priceminister/jboss/client/concurrent.jar:/appli/priceminister/jboss/client/jboss-common-client.jar:/appli/priceminister/jboss/client/jboss-jaxrpc.jar:/appli/priceminister/jboss/client/hibernate3.jar:/appli/priceminister/jboss/client/logkit.jar:/appli/priceminister/jboss/client/cglib-2.1.jar:/appli/priceminister/jboss/client/velocity-dep-1.4.jar:/appli/priceminister/jboss/client/mail.jar:/appli/priceminister/jboss/client/jbossha-client.jar:/appli/priceminister/jboss/client/jboss-aop-jdk50.jar:/appli/priceminister/jboss/client/jboss-ejb3.jar:/appli/priceminister/jboss/client/jboss-saaj.jar:/appli/priceminister/jboss/client/namespace.jar:/appli/priceminister/jboss/client/jboss-juddiaxis.jar:/appli/priceminister/jboss/client/commons-discovery.jar:/appli/priceminister/jboss/client/jboss-iiop-client.jar:/appli/priceminister/jboss/client/getopt.jar:/appli/priceminister/jboss/client/jbosssx-client.jar:/appli/priceminister/jboss/client/jmx-invoker-adaptor-client.jar:/appli/priceminister/jboss/client/wsdl4j.jar:/appli/priceminister/jboss/client/jboss-system-client.jar:/appli/priceminister/jboss/client/jbossmq-client.jar:/appli/priceminister/jboss/client/jboss-client.jar:/appli/priceminister/jboss/client/asm.jar:/appli/priceminister/jboss/client/jboss-j2ee.jar:/appli/priceminister/jboss/client/jboss-jsr77-client.jar:/appli/priceminister/jboss/client/axis-ws4ee.jar --userid 10802793 --profileid 4028937 --originalfile priceminister-vivos.txt.pm Tous les fichiers n'ont pas été traités, veuillez consulter le fichier log/ftp.lst.exp.bad pour corriger le soucis puis relancer le script. [pmas@esculape advert_import_script]$ |
| Commentaire de Judd OSullivan [ 12/oct./06 14:53 ] |
| Copie un jndi.properties dans le répertoire /data/priceminister/batch. Prend l'exemple qui se trouve sur hercule. |
| Commentaire de Eric Vannier [ 12/oct./06 15:20 ] |
|
J'ai copié le jndi.properties, batch.properties et jdbc.properties. J'ai conservé car déjà présent le batchlist sur esculape. j'ai mis ces trois fichiers dans "/data/priceminister/batch". qd je lance , j'ai l'erreur suivante : java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: EJBException:; nested exception is: javax.ejb.EJBException: null; CausedByException is: null; CausedByException is: No such entity!; nested exception is: javax.ejb.EJBException: null; CausedByException is: No such entity! at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:325) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) at java.lang.Thread.run(Thread.java:595) at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126) at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source) at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:118) at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:227) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:167) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55) at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:169) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:86) at $Proxy0.create(Unknown Source) at com.babelstore.datafile.client.DataFileClient.main(DataFileClient.java:90) Caused by: java.rmi.ServerException: EJBException:; nested exception is: javax.ejb.EJBException: null; CausedByException is: null; CausedByException is: No such entity!; nested exception is: javax.ejb.EJBException: null; CausedByException is: No such entity! at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:352) at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:125) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:93) at org.jboss.ejb.EntityContainer.internalInvokeHome(EntityContainer.java:508) at org.jboss.ejb.Container.invoke(Container.java:894) at sun.reflect.GeneratedMethodAccessor148.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80) at org.jboss.mx.server.Invocation.invoke(Invocation.java:72) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644) at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:805) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:406) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) at java.lang.Thread.run(Thread.java:595) Caused by: javax.ejb.EJBException: null; CausedByException is: null; CausedByException is: No such entity!; nested exception is: javax.ejb.EJBException: null; CausedByException is: No such entity! at com.babelstore.datafile.business.DataFileBusinessBean.ejbCreate(DataFileBusinessBean.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.ejb.plugins.CMPPersistenceManager.createEntity(CMPPersistenceManager.java:181) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.createEntity(CachedConnectionInterceptor.java:266) at org.jboss.ejb.EntityContainer.createHome(EntityContainer.java:766) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.invocation.Invocation.performCall(Invocation.java:345) at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(EntityContainer.java:1113) at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:90) at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySynchronizationInterceptor.java:192) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:212) at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:90) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:117) at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:61) at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(EntityCreationInterceptor.java:28) at org.jboss.ejb.plugins.CallValidationInterceptor.invokeHome(CallValidationInterceptor.java:41) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:109) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:335) at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:146) at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:116) at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:121) ... 24 more L'import a échoué, on déplace le fichier [10802793_stock_4028937_priceminister-vivos.txt.pm] dans le répertoire d'origine pour qu'il soit à nouveau traité |
| Commentaire de Eric Vannier [ 16/oct./06 09:58 ] |
|
Peux-tu me résumer ce que tu as fait Vendredi car ça a résolu le pb ? Merci |
| Commentaire de Judd OSullivan [ 16/oct./06 10:59 ] |
|
Apparement le client voulait un log4j.xml que j'ai copié
dans ~/batch/. Ca serait bien de mettre la même version de ce fichier
qu'il y a sur hercule (j'ai copié une version d'ailleurs). Le plantage avec l'entity not found n'est pas très utile malheureusement. A voir si on peut faire mieux. |
| Commentaire de Eric Vannier [ 16/oct./06 11:42 ] |
| Bacchus et esculape sont prêt pour subir une batterie de test avant l'import réel. |
| Commentaire de Eric Vannier [ 14/nov./06 12:10 ] |
|
Le basculement a été réalisé hier dans la journée via la modification des serveurs dn pour ftp.priceminister.com. Maintenant, il suffit d'observer si aucun problème survient au niveau des imports, du bi et des commerciaux. |
| Commentaire de Eric Vannier [ 21/nov./06 18:03 ] |
|
Je clôture cette demande car j'ai plus aucun partenaire qui arrive sur Phaeton. Le BI ont migré le seul script qui utilisait le ftp pour utiliser celui de bacchus. J'ai migré et validé les comptes ftp des commerciaux (newsletter, adoc, popup, affiliation et visuels) |
[BIN-232] [Routage] : envoi one shot du mail PMV crédité non activé début décembre Création: 28/nov./06 16:27 Mise à jour: 26/nov./07 13:25 Echéance: 08/déc./06 00:00 Résolue: 26/nov./07 13:25 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Alexandra Viravaud | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | 2 heures | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | 2 heures | ||
| Liens des demandes: |
|
||||||||||||||||
| Pays: |
FRA - France
|
||||||||||||||||
| Description |
|
Salut agathe, nous souhaitons refaire un envoi du mailing PMV crédité non activé sur la 1ère semaine de décembre. Les critères de l'extraction sont les mêmes que ceux que nous avions utilisés pour l'envoi en 1 shot de mai dernier avec une condition supplémentaire qui est : Exclure ceux qui avaient un PMV crédité non activé avant le 22/05/2006. Penses-tu pouvoir me fournir un fichier des détenteurs de PMV crédité non activés depuis le 22/05/2006 avec : leur adresse-email leur pseudo le solde disponible sur leur PMV la date de crédit de leur PMV Nous ferons cet envoi sur le compte secondaire d'EMV avant la fin de la semaine prochaine. Penses-tu pouvoir être dans les temps ? Je sais que je te préviens un peu tard mais nous n'avons pas d'autre choix que de faire l'envoi au moins 3 semaines avant qu'on nous coupe nos accès sur EMV... |
| Commentaires |
| Commentaire de Agathe Remy [ 28/nov./06 18:07 ] |
|
Mohamed, Peux-tu voir avec Alex comment faire son extraction dans BI? Merci:-) Agathe |
| Commentaire de Mohamed Ezzouak [ 04/déc./06 18:40 ] |
|
Nous avons fait avec Alexandra un rapport qui liste les
pseudo/email qui ont un solde PMV positif et qui n'ont pas activé leur
PMV depuis Juin 2006. Nous n'avons pas pu poser de conditions pour ne prendre que les PMV non activé depuis le 22/05/2006 car nous n'avons pas d'objets avec le jour. Nous avons donc pris l'objet sur le mois qui nous a permis de filtrer les PMV non activés depuis Juin 2006. Il y a donc 8 jours qui ne sont pas analysés. |
| Commentaire de Agathe Remy [ 11/déc./06 13:46 ] |
|
Alex, Peux-tu me donner le nom du rapport que vous avez fait avec Mohamed pour traiter cette problématique? Merci:-) Agathe |
| Commentaire de Alexandra Viravaud [ 11/déc./06 14:38 ] |
|
On ne l'a pas enregitré car c'était pendant la période précédent le passage à la nouvelle version BI. Au mieux, je peux te faire suivre le tableau excel de l'extract. |
| Commentaire de Agathe Remy [ 11/déc./06 16:05 ] |
|
Alex, J'aimerais que tu essaies de recréer le rapport dans Mes Favoris tant que c'est encore frais parce que je pense que nous en aurons encore besoin. Peux-tu le faire cette semaine afin que je le valide? Je reste à ta disposition si tu as des questions et n'hésite pas à nous contacter si tu as besoin d'aide! Agathe |
Nettoyage : retirer tout le code hitbox/websitestory
(APP-11697)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | XITI |
| Affecte la/les version(s): | 12.0.0 |
| Version(s) corrigée(s): | 38.0.0 (TX-D Bis) |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | Alexandre Garnier | Attribution: | Patrick Pereira |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Projets PM: | *** A PLANIFIER *** |
| Classif1: | IG |
| Classif2: | IG - xiti |
| Projets PM archivés: | Maintenance CTN-B |
| Description |
|
Pour le moment, afin de gérer les branches CVS, les colonnes HitBox on juste été dupliquées. Lorsque cela sera bon pour tout le monde, il faudra les supprimer et adapter les Business associés. ADMINISTRATION -> BRAND -> STATISTICS_HITBOX_1/2 USER -> UST_GROUP -> STATISTICS_HITBOX_1/2 |
| Commentaires |
| Commentaire de Alexandre Garnier [ 14/sept./07 12:32 ] |
| Attention à vérifier que le BI utilise bien les nouvelles colonnes. |
| Commentaire de Alexandre Garnier [ 28/sept./07 12:05 ] |
|
1ère étape faite : génération des generated avec exclusion de ces colonnes. Au niveau BI, c'est bon sur le passage vers brand.statistics_xiti et ust_group.statistics_1/2 ? Je crains que pour brand, l'info ai été oublié dans le wiki : disparition des colonnes statistics_hitbox1/2 (déjà nulles pour les nouveau co branding, mais p-e à conserver au niveau BI) au profit de la colonne statistics_xiti |
| Commentaire de Alexandre Garnier [ 02/janv./08 11:44 ] |
| Attendre la fin de la branche NPF9 |
| Commentaire de Alexandre Garnier [ 16/sept./08 17:33 ] |
|
On vient de se retrouver avec ces colonnes en DEV. Elles existent encore en INTEG aussi. A voir en PROD. Le script se trouve dans : V:\Database\old\V21\V21_0_0\prod\04_POST_DEPLOY\V20_0_0_ALL_ Il vient d'être repassé en DEV. garniera@boulard:/home/Groups/technique/Database 17:17:03 $ find . -name * ./old/V20/V20_0_0/dev/log/V20_0_0_ALL_ ./old/V20/V20_0_0/dev/log/V20_0_0_ALL_ ./old/V18/V18_0_0/dev/log/V18_0_0_ALL_ ./old/V18/V18_0_0/dev/log/V18_0_0_ALL_ ./old/V21/V21_0_0/prod/04_POST_DEPLOY/V20_0_0_ALL_ ./old/V21/V21_0_0/integ/04_POST_DEPLOY/log/V20_0_0_ALL_ ./old/V21/V21_0_0/integ/04_POST_DEPLOY/log/V20_0_0_ALL_ ./old/V21/V21_0_0/integ/04_POST_DEPLOY/log/V20_0_0_ALL_ ./CTN_G/dev/log/CTN_G_ALL_ ./CTN_G/dev/log/CTN_G_ALL_ ./CTN_G/dev/log/CTN_G_ALL_ |
| Commentaire de Patrick Pereira [ 07/janv./09 15:54 ] |
| C'est fait. |
[EXP-3498] Ajouter les adresses locales des serveurs web dans le fichier nonblock.list Création: 17/avr./07 16:23 Mise à jour: 25/juin/07 19:00 Résolue: 03/mai/07 09:47 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Critique |
| Rapporteur: | Patrice Boulanger | Attribution: | Jérémie Bennejean |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Description |
|
Dans les logs des serveurs Web, on trouve: [Tue Apr 17 01:57:53 2007] [error] [client 212.23.167.8] client denied by server configuration: root_games [Tue Apr 17 01:57:53 2007] [error] [client 212.23.167.8] client denied by server configuration: 403.html [Tue Apr 17 01:57:54 2007] [error] [client 212.23.167.8] client denied by server configuration: Tel-PDA [Tue Apr 17 01:57:54 2007] [error] [client 212.23.167.8] client denied by server configuration: 403.html [Tue Apr 17 01:57:55 2007] [error] [client 212.23.167.8] client denied by server configuration: tab_600 [Tue Apr 17 01:57:55 2007] [error] [client 212.23.167.8] client denied by server configuration: 403.html [Tue Apr 17 01:57:56 2007] [error] [client 212.23.167.8] client denied by server configuration: tab_700 [Tue Apr 17 01:57:56 2007] [error] [client 212.23.167.8] client denied by server configuration: 403.html [Tue Apr 17 01:57:57 2007] [error] [client 212.23.167.8] client denied by server configuration: bargain [Tue Apr 17 01:57:57 2007] [error] [client 212.23.167.8] client denied by server configuration: 403.html [Tue Apr 17 01:57:58 2007] [error] [client 212.23.167.8] client denied by server configuration: root_white [Tue Apr 17 01:57:58 2007] [error] [client 212.23.167.8] client denied by server configuration: 403.html [Tue Apr 17 01:57:59 2007] [error] [client 212.23.167.8] client denied by server configuration: root_baby [Tue Apr 17 01:57:59 2007] [error] [client 212.23.167.8] client denied by server configuration: 403.html [Tue Apr 17 01:58:00 2007] [error] [client 212.23.167.8] client denied by server configuration: root_clothing [Tue Apr 17 01:58:00 2007] [error] [client 212.23.167.8] client denied by server configuration: 403.html Il semblerait donc que minitor s'amuse à bloquer le serveur web lui-même lors de la génération des pages statiques. Comme c'est assez ennuyeux, je propose d'ajouter les adresses locales des serveurs dans le fichier nonblock.list. |
| Commentaires |
| Commentaire de Jérémie Bennejean [ 17/avr./07 16:48 ] |
|
J'ai rajouté dans le nonblock.list de PHAETON #ADRESSES PHAETON 212.23.167.28 212.23.167.24 212.23.167.21 212.23.167.22 212.23.167.4 212.23.167.5 212.23.167.6 212.23.167.7 212.23.167.8 212.23.167.9 212.23.167.10 212.23.167.11 212.23.167.12 212.23.167.13 212.23.167.14 212.23.167.15 212.23.167.16 212.23.167.20 212.23.167.23 212.23.167.25 CUPIDON #ADRESSES CUPIDON 212.23.167.30 212.23.167.31 212.23.167.32 212.23.167.33 212.23.167.34 212.23.167.35 212.23.167.36 212.23.167.37 212.23.167.38 212.23.167.39 212.23.167.43 212.23.167.44 212.23.167.45 212.23.167.46 212.23.167.47 212.23.167.48 ARICIA 212.23.170.247 Les adresses suivantes existaient deja dans le nonblock.list de aricia 212.23.170.244 212.23.170.241 212.23.170.248 212.23.170.243 212.23.170.242 212.23.170.251 212.23.170.249 212.23.170.252 212.23.170.253 212.23.170.240 212.23.170.246 212.23.170.250 212.23.170.245 212.23.170.254 Sur chaque serveur web j'ai fais un configtest et un graceful |
| Commentaire de Jérémie Bennejean [ 19/avr./07 15:49 ] |
| Malgré l'ajout des adresses dans le fichiers de chacun des serveurs webs, il y a toujours ces erreurs dans les logs |
| Commentaire de Jérémie Bennejean [ 30/avr./07 11:18 ] |
|
[mrtg@phaeton mrtg]$ grep -ir nonblock.list * minitord/bin/apache_block_ip.pl:my $white_list = "/data/chrootapache/usr/local/apache/conf/nonblock.list"; |
| Commentaire de Jérémie Bennejean [ 30/avr./07 11:20 ] |
|
Sur aricia l'@ (212.23.170.248) en deny correspond au vh-intra Sur phaeton l'@ (212.23.170.8) en deny correspond au vh-eglue, vh-bo,vi-intra,vh-bi Sur cupuidon l'@ (212.23.170.33) en deny correspond au vh-eglue, vh-bo,vi-intra,vh-bi |
| Commentaire de Jérémie Bennejean [ 30/avr./07 14:10 ] |
| Pour résoudre l'apparition de certaines erreurs dans le error_log, j'ai ajouté dans la conf apache de cupidon (dans 1 er temps et faire le test) au sein des vh eglue et bi dans la Allow from 212.23.170.33 |
| Commentaire de Jérémie Bennejean [ 30/avr./07 14:56 ] |
|
Pour faire face à cette erreur qui revient tres souvent j'ai
fais un touch du fichier demandé. J'ouvre aussi un jira à l'équipe de
swan. [Mon Apr 30 13:52:26 2007] [error] [client 195.12.230.196] File does not exist: /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V14_0_1/front/brand/www/images/default/bullet/a_arrowb2.gif---> OK touch a_arrowb2.gif |
| Commentaire de Jérémie Bennejean [ 30/avr./07 14:58 ] |
| idem [Mon Apr 30 14:54:15 2007] [error] [client 82.228.143.55] File does not exist: /usr/local/apache/htdocs/pmweb/virtualhost-www/content/V14_0_1/front/brand/www/images/default/bullet/a_arrowb2.gif, referer: https://www.priceminister.com/connect?action=login&dest=%2Fpurchase%3Faction%3Dsalelist%26login%3Dmargo1230_3&login=margo1230_3 |
| Commentaire de Jérémie Bennejean [ 30/avr./07 15:01 ] |
|
sur phaeton: [Mon Apr 30 13:42:36 2007] [error] [client 195.12.230.202] File does not exist: /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V14_0_1/front/brand/www/images/default/bullet/a_arrowb2.gif, referer: http://www.priceminister.com/navigation/search/category/search_books/keyword/singer-christiane/ss/70 [Mon Apr 30 14:36:34 2007] [error] [client 82.241.240.95] File does not exist: /usr/local/apache/htdocs/pmweb/virtualhost-www/content/V14_0_1/front/brand/www/images/default/bullet/a_arrowb2.gif, referer: https://www.priceminister.com/connect?action=login&c=81&dest=%2Fcheckout%3Faction%3Daddress |
| Commentaire de Jérémie Bennejean [ 30/avr./07 15:05 ] |
|
sur aricia : [Mon Apr 30 14:54:15 2007] [error] [client 82.228.143.55] File does not exist: /usr/local/apache/htdocs/pmweb/virtualhost-www/content/V14_0_1/front/brand/www/images/default/bullet/a_arrowb2.gif, referer: https://www.priceminister.com/connect?action=login&dest=%2Fpurchase%3Faction%3Dsalelist%26login%3Dmargo1230_3&login=margo1230_3 [Mon Apr 30 12:43:11 2007] [error] [client 86.201.188.113] File does not exist: /usr/local/apache/htdocs/pmweb/virtualhost-camif/content/V14_0_1/front/brand/www/images/default/bullet/a_arrowb2.gif, referer: https://occasion.camif.fr/connect?action=login&c=81&dest=%2Fcheckout%3Faction%3Daddress |
[BIN-343] [Finance] : Détail des sommes à rembourser aux acheteurs Création: 26/juin/07 15:14 Mise à jour: 18/mars/10 12:33 |
|
| Etat: | Ré-ouvert |
| Projet: | Business Intelligence |
| Composants: | Finance |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Philippe Favrot | Attribution: | Julien Girardet |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
DMR - buyer refund v2.0.doc
|
| Pays: |
ALL - Tous
|
| Description |
|
Bonjour, Nous poursuivons nos travaux de "mise au carré" de la comptabilisation des claims (ZVRA / PVRA / PVZA) par la partie remboursements aux acheteurs. Nous avons d'un côté les montants à rembourser aux acheteurs (reportés dans le rapport "claims status") : - buyer bonus (PVRA / ZVRA) - buyer payment (ZVRA) et de l'autre les sommes réellement remboursées aux acheteurs par crédit sur leur PMV (type : credit_BO ; cause : remboursement). Nous avons besoin d'avoir à la fin de chaque mois la liste des sommes (pseudos / numéro de panier / date d'autorisation / montant ...) restant dues aux acheteurs (ie somme en attente de crédit sur les PMV). Nous restons, Claudie et moi, à votre disposition pour préciser cette demande. Merci Philippe |
| Commentaires |
| Commentaire de Romain Czornomaz [ 28/août/07 12:06 ] |
|
Philippe, Après investigation avec les équipes dev, il n'est pas possible en l'etat de fournir un rapport avec les numeros de paniers , dates d'autorisation, montants à rembourser aux acheteurs en attente. En effet pour cela, nous devons nous baser sur les operations PMV et il n'existe pas actuellement de lien entre les operations et les items ou paniers. Je te propose que nous attendions le retour d' Agathe la semaine prochaine pour en discuter avec elle et essayer de trouver une solution. Merci de ta compréhension, Romain |
| Commentaire de Agathe Remy [ 18/févr./08 11:24 ] |
|
Nouveau rapport sur les remboursements acheteurs en attente de paiement sur le PMV (~400 000 euros). Ce rapport risque de nécessiter la mise en relation entre les opérations et les transactions qui aujourd'hui n'existe que dans un champ « description ». A spécifier... |
| Commentaire de Agathe Remy [ 25/juil./08 20:39 ] |
|
Philippe, Ce JIRA est-il toujours d'actualité ? Agathe |
| Commentaire de Dalila Belkebir [ 19/août/08 14:44 ] |
|
Bonjour Claudie, Tu trouveras disponible en production (FR & ES) les changements suivants : - Prise en compte de l'Item Buyer Bonus dans le calcul du Total Refund Amount pour les claims ZVRA dans les rapports : « buyer debt summary » « buyer debt by claim closing month » « buyer refund operation » (déjà pris en compte auparavant) - Mise en négatif du Total Refund Amount pour les Remboursement à tort (operation cause id = 80) dans le rapport : « buyer refund operation » - Création d'un répertoire Histo_Financial afin de permettre de marginaliser le rapport (rapport toujours disponible mais non utilisé) : « buyer debt » Dalila. |
| Commentaire de Agathe Remy [ 15/sept./08 11:03 ] |
|
Bonjour Claudie, S'il te plait, peux-tu valider ces modifs? Merci. Agathe |
| Commentaire de Dalila Belkebir [ 15/oct./08 16:37 ] |
|
Retour de Claudie sur le rapport Buyer refund operation : 1- ce rapport reprend l'ensemble des opérations qui ont été payées aux acheteurs. Le total de la colonne « operation cause » doit pouvoir être rapproché des mouvements sur le PMV issus du rapport « BO operations by cause ». Cf détail du rapprochement ci-dessous. Il ressort un écart sur le total de la cause « remboursés à tort » et le total de la cause « remboursement » 2- Je pense que l'écart s'explique en partie, par les « anomalies » ci-dessous : En effet, je ne comprends pas pourquoi les causes « paiement vente » et « payé à tort » apparaissent. Ces causes concernent uniquement les vendeurs. **** « Payé à tort », une seule opération, cf ci-dessous extrait du rapport Je pense que cette ligne ne devrait tout simplement pas apparaitre (Le payé à tort concerne le vendeur « 19teca74 », on retrouve la transaction correspondante dans le seller credit) **** « Paiement vente », trois opérations, cf ci-dessous, extrait du rapport : Ces trois acheteurs, après consultation dans back office, ont bien été remboursés de 13.70, 30.80 et 78.30 euros. Ce qui aurait du apparaitre dans le rapport c'est la cause « remboursement » et les montants suivants en « operation amount » de 13.70, 30.80, 78.30. Ces paiements vente concernent respectivement les vendeurs suivants : librosonline, stabiloxxpro , luzern-es La claim aurait du être annulée mais elle a été maintenue suite blocage système, et les vendeurs ont donc fait l'objet d'un paiement vente pour qu'ils puissent être payés. |
| Commentaire de Agathe Remy [ 27/nov./08 11:19 ] |
|
Bonjour Julien, Peux-tu développer les rapports? L'objectif est de livrer les rapports en France et en Espagne avant le 10/12/2008. Merci! Agathe |
| Commentaire de Agathe Remy [ 27/nov./08 11:21 ] |
|
Voici les spécifications des rapports de rapprochement des
remboursements acheteurs avec les transactions, validées par Claudie le
27/11/2008. Elles sont également disponibles dans le répertoire : V:\Reporting\BusinessIntelligence\En Développement\2008-10 Buyer debt Agathe |
| Commentaire de Agathe Remy [ 17/févr./09 11:43 ] |
|
Agathe, Comme vu ensemble, voici ci-joint la synthèse de l'analyse des rapports « buyer refund... » sur l'Espagne. Sur le premier onglet, j'ai donc ajouté une synthèse des écarts mis en évidence (en espérant qu'elle soit suffisamment claire) : - Ecart sur le total des remboursements issus des rapports « buyer refund... » et « wallet operation by month » - Ecart sur le total des colonnes des rapports "buyer refund..." onglet ZVRA et PVRA (total des transactions hors doublon) N'hésite pas à revenir vers moi si tu as besoin d'explication ou précision sur cette synthèse Merci à toi claudie |
| Commentaire de Agathe Remy [ 17/févr./09 11:44 ] |
|
Bonjour Claudie, Je reviens vers toi sur les écarts dans les rapports « buyer refund » Concernant l'écart sur le total des colonnes dans les onglets ZVRA et PVRA, nous avons identifié l'erreur et donc nous allons la corriger  Pour l'écart sur le total des remboursements issus des rapports « buyer refund... » et « wallet operation by month » : Le rapport "Buyer refund by claim closing month" se base sur la "claim closing date" de la transaction, alors que les rapports " Buyer refund without claim by completion month" et "Wallet operations by user" se base sur la completion date de l'opération. Donc l'écart provient des opérations liées à une transaction dont la completion date est inférieur à 2009 mais dont la claim closing date est supérieur à 2009 et donc n'apparaissent pas dans les rapports. Souhaites tu que les rapports évoluent pour prendre en compte ces transactions ? N'hésite pas à nous solliciter pour plus d'informations. Julien. |
| Commentaire de Julien Girardet [ 25/févr./09 16:41 ] |
|
Bonjour Claudie, les totaux des rapports "Buyer refund by claim closing month" et "Buyer refund without claim by completion month" sont corrigés. Tu trouveras dans "Financial/Accounting" les versions corrigées de ces rapports en France, Spain et UK. Julien. |
| Commentaire de Agathe Remy [ 17/août/09 15:38 ] |
|
Bonjour Philippe, S'il te plait, peux-tu valider cette demande afin que nous puissions la clôturer? Merci. Agathe |
| Commentaire de Agathe Remy [ 18/août/09 10:00 ] |
|
le 23/03/2009 : Bonjour Agathe, Je voudrais commencer à exploiter les rapports « buyer refund » sur la France à partir des données à fin mars 2009, 1ère analyse sur les remboursements puis plus tard finaliser l'analyse sur les remboursés à tort quand les rapports seront dispo. Nous avions édité les rapports à fin 2008 avant que les rapports ne soient définitifs. Il nous faut donc aujourd'hui rééditer ces rapports pour tout l'historique du 01/01/2001 au 31/03/2009. Il s'agit donc d'une édition très très lourde parce que très longue et cela suppose aussi d'éditer pour nous les rapports en morcelant les périodes. Tu m'avais évoqué il y a quelque temps la possibilité de lancer ces rapports en une seule fois via le BI. Peux-tu me dire si cela est possible ? On pourrait alors imaginer l'édition des deux rapports (« buyer refund by claim closing month » et «buyer refund without any claim ») de la façon suivante : - Du 01/01/2001 au 31/12/2006 à la date que vous voulez puisqu'il n'y a à priori plus de mouvement sur les claims datant de cette période - Du 01/01/2007 au 31/12/2008 le jour où les opérations du mois sont stabilisées (ce rapport serait à lancer tous les mois) - 2009 serait édité par nous Peux-tu nous tenir info, Merci à toi claudie |
| Commentaire de Agathe Remy [ 18/août/09 10:00 ] |
|
le 10/04/2009 : Bonjour Claudie, Tu trouveras l'historique des rapports « Buyer refund » dans le répertoire : T:\BI\00 - Projets\2009-04 Historique Buyer Refund ¿ Buyer refund by claim closing month ¿ Buyer refund without claim by completion month L'historique a été généré le jour de la stabilisation des chiffres du mois de Mars, c'est-à-dire Mardi dernier (07/04/09) Et donc la période est du 01/01/2001 au 07/04/2009 A ta disposition pour plus d'informations. Julien. |
| Commentaire de Dalila Belkebir [ 30/sept./09 13:49 ] |
|
Bonjour Philippe, S'il te plait, peux-tu valider cette demande afin que nous puissions la clôturer? Sinon nous communiquer ce qu'il reste à faire. Merci. Dalila. |
| Commentaire de philippe favrot [ 30/sept./09 17:23 ] |
|
Dalila, c'est à Claudie de nous dire si on peut clôturer ce Jira ; pour être honnête je ne sais pas précisément où nous en sommes de ce chantier. J'avais en revanche, compris que nous le laissions de côté pendant le congés maternité d'Agathe. Maintenant si vous avez du temps pour avancer dessus, c'est bienvenu ! A voir avec Claudie Merci Philippe |
| Commentaire de Claudie Dufresne [ 01/oct./09 18:20 ] |
|
Dalila, Ce Jira est toujours en cours. Une première étape a été possible via les rapports "buyer debt". Ces rapports permettent en effet de faire un premier travail d'analyse des remboursements effectués par type de claim notamment. Travail effectué sur l'Espagne et UK. Pour la France, l'analyse de l'antériorité, beaucoup plus volumineuse et "évolutive", est en toujours en cours. les rapports "buyer debt" sont un premier outil d'analyse de l'antériorité, mais d'autres rapports seront nécessaires. 1- rapports de type "buyer debt" ne prenant en compte que les variations du mois 2- rapport permettant de lister les sommes (pseudos / numéro de panier / date d'autorisation / montant ...) restant dues aux acheteurs (ie somme en attente de crédit sur les PMV). A votre dispo si vous voulez qu'on fasse un point merci claudie |
[APP-20603] BDD tél fixes --> flux Création: 22/mai/08 14:38 Mise à jour: 21/juil./08 18:37 Résolue: 18/juil./08 18:03 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 21.0.0 |
| Version(s) corrigée(s): | 26.0.0 (TX-B) |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Ghislain Gridel | Attribution: | Renaud Dierickx |
| Résolution: | Corrigé | ||
| Σ Estimation restante: | Non spécifié | Estimation restante: | Non spécifié |
| Σ Temps consacré: | Non spécifié | Temps consacré: | Non spécifié |
| Σ Estimation originale: | Non spécifié | Estimation originale: | Non spécifié |
| Pièces jointes: |
screenshot-1.jpg
Solution_flux_BDD_Tel_fixe.JPG
|
||||||||||
| Sous-tâches: |
|
||||||||||
| Pays: |
FRA - France
|
||||||||||
| Site: | Prod | ||||||||||
| Projets PM: | *** RESERVE *** | ||||||||||
| Classif FONC: | comarket |
| Description |
|
Bonjour, Nous commercialisons la BDD de tél fixe via notre partenaire scanclic et pour cela nous devons avoir l'accord des PriceMembers pour commercialiser leur n° de tél fixe. Nous souhaiterions donc rajouter un bouton radio opt-in "Par téléphone" en-dessous du bouton "SMS "sur la page d'inscription. Voir ci-joint. Ce bouton servira à optiniser les nouveaux membres. Il faut coordonner cela avec Agathe pour que l'info puisse être envoyée à PN DATA par la suite. Merci. |
| Commentaires |
| Commentaire de Ghislain Gridel [ 26/mai/08 11:53 ] |
|
Bonjour, cette demande est assez urgente. Savez-vous quand le bouton radio pourra être en ligne ? |
| Commentaire de Emeric Teil [ 04/juin/08 12:37 ] |
| Comme vu ensemble, on prend cette demande pour notre prochaine version. Celle-ci sortira soit fin juillet, soit fin aout... |
| Commentaire de Emeric Teil [ 04/juil./08 17:35 ] |
| OK en Dev |
| Commentaire de Ghislain Gridel [ 08/juil./08 11:40 ] |
| Recette ok. Merci. |
| Commentaire de Olga Costa [ 18/juil./08 14:57 ] |
| Il faut publier? |
| Commentaire de Ghislain Gridel [ 18/juil./08 16:07 ] |
|
oui. Merci Olga. Pourrais-je avoir le ien de désabonnement ? |
| Commentaire de Renaud Dierickx [ 18/juil./08 16:58 ] |
|
Pour les urls de désabonnement, tout est sur les serveurs de recette en BO. Marketing > Abonnements : liste > Voir screenshot-1 Les serveurs DEV TEST 6 et 7 ==> /subscription?action=unsubscribe&email=prenom.nom%40domaine.fr&userid=123456&mailsubscriptionid=32 |
| Commentaire de Ghislain Gridel [ 21/juil./08 10:47 ] |
|
Merci Renaud, donc dela donnera ça ? www.priceminister.com/subscription?action=unsubscribe&email=prenom.nom%40domaine.fr&userid=123456&mailsubscriptionid=32 Dalila tu confirmes ? Dalila, peux-tu compléter le JIRA avec les dates d'envoi des données à PN Data, stp ? Merci ! |
| Commentaire de Dalila Belkebir [ 21/juil./08 15:04 ] |
|
Ghislain, Désolée, mais je ne peux rien confirmer quant à l'URL que tu communiques. Lors de notre précédent point, il était prévu que : - tu crées un JIRA dédié à l'équipe BI, - tu détermines avec l'aide de 1000mercis les critère de la cible pour l'envoi afin de déterminer si l'on doit la valider de notre côté, - les modifications du flux seront prises en compte lors de l'envoi mensuel du 02/09/2008 (attention, lors du flux 02/09/08 seules les données Optin fixe mises à jour (MAJ volontaires ou nouveaux inscrits) après envoi du mail seront remontées) Pour ma part, je vais mettre à jour les spécifications et les développements du flux avec PN_DATA en fonction des informations que tu préciseras dans le nouveau JIRA. Dalila. 97.48 |
| Commentaire de Emeric Teil [ 21/juil./08 18:37 ] |
| OK en Integ. On ferme donc de notre côté. Merci, comme le suggère Dalila, de créer un Jira dédié au BI. |
[BIN-335] Ecart entre Titan et BO Création: 23/mai/07 08:54 Mise à jour: 14/sept./07 18:04 Résolue: 28/mai/07 14:27 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Finance |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Bloquant |
| Rapporteur: | Philippe Favrot | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
etude écarts panier coupon article avril 07.xls
exploit panier coupon article_avril 07.xls
Purchases_summary_by_month (avril 07).xls
|
| Pays: |
FRA - France
|
| Description |
|
Bonjour, écart entre Titan et BO au niveau du VA capturé pour avril : Titan : 5 374 188 BO : 5 375 088 en pièce attachée : - rapport Titan panier coupon article - exploitation de ce rapport - rapport purchase summary by month (B0). Merci Philippe |
| Commentaires |
| Commentaire de Philippe Favrot [ 23/mai/07 08:55 ] |
|
pas possible de joindre le rapport Titan car plus de 10 Mo. Je te le passe par amil. Philippe |
| Commentaire de Agathe Remy [ 25/mai/07 17:33 ] |
|
Philippe, J'ai vérifié les données et elles sont identiques sur Titan et dans le DataWarehouse En faisant la même requête sur Titan, j'obtiens bien 5 375 088 pour le montant capturé. Maintenant, il s'agit de savoir pourquoi le rapport généré sur Titan ne donne pas les mêmes chiffres... Agathe |
| Commentaire de Agathe Remy [ 25/mai/07 18:27 ] |
|
Es-tu sur de ton traitement du fichier
panier_coupons_articles? Parce que j'obtiens les mêmes chiffres sous BI
et sur Titan... Agathe |
| Commentaire de Agathe Remy [ 28/mai/07 14:27 ] |
|
Philippe, Dans le fichier ci-joint, tu trouveras le résultat de l'étude sur les écarts. Il y a 900¿ d'écarts répartis sur le 24/04 (85¿) et le 29/04 (815¿). Sur la journée du 29/04, j'ai comparé les résultats de ma requête sur titan (qui donne les mêmes résultats que le rapport BI) et celle d'un fichier panier_coupons_articles dans l'intranet. Les données sont identiques. La conclusion est donc : - soit une erreur s'est produite lors de l'exploitation du fichier panier_coupons_articles dans Excel - soit le fichier panier_coupons_articles exploité dans Excel était antérieur à la date de stabilisation des montants Je clôture donc ce JIRA. Agathe |
[BIN-467] [Back-Office] : Ajout d'une dimension fabricant dans les univers Advert et Item Création: 27/juin/08 13:10 Mise à jour: 09/sept./08 10:53 |
|
| Etat: | Ouvert |
| Projet: | Business Intelligence |
| Composants: | BackOffice |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Cedric Favero | Attribution: | Julien Girardet |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Pour pouvoir sortir des rapports pointus sur la contrefaçon ,
j'ai besoin de sortir des rapports aussi bien dans Advert que Item avec
accès au champ ProductManufacturerName car je n'ai aujourd'hui accès
qu'au titre de la fiche. Il me faudrait donc dans ces 2 univers et dans le dossier Product une dimension ProductManufacturerName. Merci d'avance. |
| Commentaires |
| Commentaire de Agathe Remy [ 07/juil./08 17:53 ] |
|
Cédric, Est-ce que la dimension que tu cherches n'est pas la suivante : Product/Product Identification/Manufacturer Id ? Elle est présente dans les univers ADVERT et ITEM. merci de ton retour. Agathe |
| Commentaire de Cedric Favero [ 07/juil./08 18:11 ] |
|
Mais çà c'est le "code fabricant ", moi je voudrais pouvoir acceder au "nom fabricant" (ProductManufacturerName) Pour pouvoir rechercher un terme dans ce dernier et pas obligatoirement spécifier un code particulier (surtout qu'ils peuvent maintenant etre générés à la volée lors de la création de fiche.) Merci. |
| Commentaire de Agathe Remy [ 08/juil./08 10:37 ] |
|
Bonjour Cédric, Je ne vois pas trop ce que tu appelles le "ProductManufacturerName". Pourrais-tu me donner un exemple et me dire où tu trouves cette information? Merci. Agathe |
| Commentaire de Cedric Favero [ 08/juil./08 11:24 ] |
|
Sur une fiche comme celle-ci: http://bo.priceminister.com/referential_back?action=productview&productid=68190319 Le fabricant est Nike et le code fabricant est PM07081451 (valeur d'attribut) Est-ce que dans la dimension Product/Product Identification/Manufacturer Id , je peux rechercher un terme comme "Nike" directement? Merci. |
| Commentaire de Agathe Remy [ 08/juil./08 14:43 ] |
|
Nous ne parlions donc absolument pas de la même chose. L'objet "Manufacturer Id" donne l'identifiant fabricant et non le code de l'attribut fabricant. Pour ta "valeur fabricant", il s'agit d'un attribut et nous ne récupérons pas encore les attributs dans BI en raison de l'instabilité due au chantier "Sauvons la Base Produit". Mais en cherchant bien, je me suis aperçue qu'il existe une dénormalisation de cet attribut qui permettrait d'en récupérer la valeur directement à partir du produit. Nous devrions donc pouvoir te mettre à disposition cette information, moyennant un peu de développement. Agathe |
| Commentaire de Cedric Favero [ 08/juil./08 15:37 ] |
|
ah zut , c'est bien l'attribut fabricant dont j'ai besoin.. Il possible de le récuperer par le summary ou ce n'est pas dans BI non plus? En fait j'ai besoin de faire des rapport sur des vendeurs avec un nb d'annonces ou de ventes pour telle ou telle marque dans le titre ou le champ fabricant. |
| Commentaire de Julien Girardet [ 08/juil./08 17:35 ] |
|
Agathe, J'ai ajouté dans l'univers Advert et Item la dimension "Product manufacturer name" dans la classe "Product" : Ajout de la table DWH.TD_PRD_ATTRIBUTE_VALUE + jointure : DWH.TD_PRD_ATTRIBUTE_VALUE.PRD_ATTRIBUTE_VALUE_KEY=TD_PRODUCT.PRD_MANUFACTURER_KEY Concernant la différence entre PRD_ATTRIBUTE_VALUE (Terra ) et TD_PRD_ATTRIBUTE_VALUE (DWH ), j'ai vu Edouard : En effet il y a eu un nettoyage de la table PRD_ATTRIBUTE_VALUE (projet "valeur privée") mais la procédure est assez complexe (plusieurs scripts : nettoyage produit, garbage collecting...) Bref si l'on veut les scripts je peux les demander a Patrick Mais malgré cette différence, il manque environ 500 000 enregistrements (voir requête : V:\Reporting\BusinessIntelligence\En Développement\2008-07 Product manufacturer name\nb_prd_attribut_value.sql). Donc j'ai préparé un script pour récupérer les enregistrements manquants (voir script : V:\Reporting\BusinessIntelligence\En Développement\2008-07 Product manufacturer name\recup_prd_attribut_value.sql) En conclusion : - Soit on nettoie et on récupère les enregistrements manquants - Soit on ne fait que récupérer les enregistrements manquants - Soit on fait un full sur la table Julien. |
| Commentaire de Cedric Favero [ 12/août/08 16:27 ] |
|
J'ai des besoins assez importants pour la cellule anti-contrefaçon. Pensez vous qu'il soit possible de sortir à court terme des rapports incluant le champ fabricant? Ex pratique : vendeurs ayant un nombre d'annonces superieur à 10 , rubrique parfums et fabricant Chanel. Merci d'avance. |
[BIN-393] [Cobranding] : rajouter une colonne commision without shipping Création: 04/déc./07 17:55 Mise à jour: 14/janv./08 10:31 Résolue: 27/déc./07 11:42 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Ghislain Gridel | Attribution: | Samir Beghdadi |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour Samir, peux-tu rajouter une colonne "commission amount without shipping" à droite de commission sur les rapports PriceMinister - Captured co-branding overview et PriceMinister - Authorized co-branding overview , stp ? Merci. Ghislain |
| Commentaires |
| Commentaire de Samir Beghdadi [ 27/déc./07 11:42 ] |
|
Bonjour, Ghislain, comme vu ensemble avec j'ai ajouté deux colonnes "commission amount without shipping" et "VAT on commission amount without shipping" dans les deux rapports PriceMinister - Captured co-branding overview et PriceMinister - Authorized co-branding overview. Agathe, veux tu les valider stp. Merci Samir |
| Commentaire de Samir Beghdadi [ 02/janv./08 14:26 ] |
|
Bonjour Ghislain, Les deux rapports "PriceMinister - Captured co-branding overview" et "PriceMinister - Authorized co-branding overview " sont en production. Merci Samir |
| Commentaire de Justin Ziegler [ 08/janv./08 15:29 ] |
|
Guislain, N'est il pas possible de stopper toute modif sur les rapports de cob ? il me semble qu'il y a un consensus pour dire que sauf exception on baisse la priorité de ces projets ? je met OM en copie. |
| Commentaire de Justin Ziegler [ 08/janv./08 15:30 ] |
|
je vois qu'OM est déja en copie. Compte tenu des priorité globale de l'équipe bi, je pense qu'on devrait évité de passer plus de temps sur les rapports de cob ! :-) |
| Commentaire de Justin Ziegler [ 08/janv./08 15:31 ] |
| D'autant plus qu'on y a deja passé énormément de temps, voire meme cela a été un des plus gros consommateur de temps coté bi. |
| Commentaire de Ghislain Gridel [ 09/janv./08 18:37 ] |
|
Ok. je comprends que cela ne soit pas une priorité. On peut le reporter à plus tard. Merci. Ghislain |
[BIN-500] [TFV] : différences sur rapport SLTV Création: 17/oct./08 16:30 Mise à jour: 06/mars/09 18:09 Résolue: 06/mars/09 18:09 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Thomas Beylot | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Classeur1.xlsx
|
| Pays: |
FRA - France
|
| Description |
|
Hello à une semaine de ma prèz au coex, je me permets de mettre cette question en "critique" en effet j'observe certaines différences la plupart du temps non significatives mais parfois oui. Mais cela ne devrait pas être exactement pareil ? voir le fichier excel en pj. thomas |
| Commentaires |
| Commentaire de Thomas Beylot [ 17/oct./08 16:32 ] |
| à noter que les rapports confid se trouvent sur http://intra.priceminister.com/stats/reports/confid/executive/seller/macro/ |
| Commentaire de Agathe Remy [ 17/oct./08 16:53 ] |
|
Thomas, Les différences en faveur du BI jusqu'en janvier mars 2006 peuvent s'expliquer par le fait que le BI prend en compte les annonces archivées contrairement au rapport sur l'ancien système. Pour les différences en négatif à partir d'avril 2006 (et inférieures à à 4%) peuvent s'expliquer par les mutations de part en pros qui ont eu lieu entre la date de génération du rapport sur l'ancien système et aujourd'hui. A vérifier. A ta dispo pour en discuter. Agathe |
| Commentaire de Agathe Remy [ 06/mars/09 18:09 ] |
|
Suite à la migration des rapports Seller macro dans BI et à
la modification de l'arborescence Produit Art&Collection, cette
demande devient obsolète. Agathe |
[BIN-547] [BACK-OFFICE] : Ajout de la dimension "Advert serial number" (Univers Advert et Item) Création: 12/janv./09 13:36 Mise à jour: 04/mars/09 11:12 Résolue: 04/mars/09 11:12 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | BackOffice |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Cedric Favero | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
screenshot-1.jpg
|
| Pays: |
FRA - France
|
| Description |
|
J'aimerais pouvoir detecter les annonces ou les articles
pour une annonce donnée en fonction du numéro de serie renseigné (cf
capture). Car on a identifié un certain nombre de numéros de série systematiquement utilisés sur des articles de contrefaçon. Donc dans le groupe Advert des univers ADVERT et ITEM avoir une dimension "Advert Serial Number" A moins que çà n'existe déjà? (pas trouvé) Merci. |
| Commentaires |
| Commentaire de Agathe Remy [ 16/janv./09 19:07 ] |
|
Bonsoir Cédric, Nous disposons bien de l'information "Advert serial number" au niveau de la transaction (ITEM). En revanche, elle a été oubliée lors de la construction de la base BI au niveau de l'annonce (ADVERT). Nous pouvons donc dans un premier temps l'ajouter dans l'univers ITEM. En revanche, il faudra attendre un prochain déploiement de l'alimentation (probablement mi-février) pour l'ajouter dans l'univers ADVERT. Agathe |
| Commentaire de Cedric Favero [ 19/janv./09 09:38 ] |
|
Ok , faites moi signe alors quand ce sera disponible dans les deux univers. Merci. |
| Commentaire de Cedric Favero [ 05/févr./09 18:11 ] |
| je ne le trouve pas dans Advert |
| Commentaire de Cyril Tanneau [ 05/févr./09 18:40 ] |
|
Oui, en effet... Comme nous te l'avions dit (voir
commentaires du Jira), l'ajout de cette dimension dans Advert nécessite
une mise en Prod de notre alimentation, qui n'est prévue que pour mi
Février. Cette dimension a donc été ajoutée dans Item pour le moment, elle le sera dans Advert très prochainement. Merci, Cyril |
| Commentaire de Cedric Favero [ 06/févr./09 09:00 ] |
|
Je pensais que çà faisait partie du lot cette sorti cette semaine. Relancez moi pour validation quand çà sera bon alors.. Merci. |
| Commentaire de Cyril Tanneau [ 04/mars/09 11:12 ] |
|
Cédric, La dimension "Advert serial number" est bien présente dans les deux univers (ITEM et ADVERT) comme demandé dans le Jira. Les données ont été initialisées et sont donc accessibles dans le BI. Merci, Cyril |
[IMP-3386] Variations de stock site UK Création: 10/mars/09 09:46 Mise à jour: 30/oct./09 15:48 Résolue: 18/mars/09 15:29 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Gaël Seguillon | Attribution: | Jérôme Viviès |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
GBR - Royaume Uni
|
| Login: | n/a |
| Séparateur: | N/A |
| Type de traitement: |
N/A
|
| Description |
|
Bonjour comme j'en ai averti Daniel la semaine dernière nous
constatons des variations de stock très importante sur le tableau de
bord BO UK ces variations sont inexplicables pour nous car dissociées
d'entrées ou sorties de fichiers de stock de pros pour exemple + variation de -6 millions de livres entre le 09 et 10 Mars de 23 millions à 17 millions à l'inverse la semaine passée augmentation du stock de jeux vidéo de 6000 à 50 000 alors que nous n'avons pas vu passé de gros fichier de pros ? merci de nous éclaircir sur l'origine de ces variations et nous assurer que les valeurs du tableau de bord sont le reflet de la réalité du stock en ligne. Gaël |
| Commentaires |
| Commentaire de Gaël Seguillon [ 10/mars/09 09:47 ] |
| Erreur dans le menu déroulant il s'agit bien d'une demande sur le site UK |
| Commentaire de Jérôme Viviès [ 10/mars/09 13:26 ] |
| Ok, j'ai repassé le JIRA côté IMP et j'ai corrigé le pays (FR => UK). |
| Commentaire de Gaël Seguillon [ 10/mars/09 13:27 ] |
| merci Jérôme j'ai été un peu vite en le validant |
| Commentaire de Frédéric Nahum [ 16/mars/09 16:52 ] |
| j'ai vérifier aujou'd'hui le stock est revenu a la normal soit 30 million d'article, je vais vérifier demain et parès demain pour voir si cela se reproduit je vous tiens au courant |
| Commentaire de Gaël Seguillon [ 16/mars/09 17:10 ] |
| Je pense que la variation n'est pas logique, comment pouvons nous avoir plus de 78 000 en stock jeux vidéo alors qu'aucun pros n'a fait d'import important su cette catégorie depuis plusieurs semaines ? |
| Commentaire de Frédéric Nahum [ 16/mars/09 18:13 ] |
| Attention il s'agit du nombre d'article (annonces x quantité) donc il suffit de 700 annonces avec des quantités de 100 et Hop et on déja 70 000 |
| Commentaire de Gaël Seguillon [ 16/mars/09 18:29 ] |
| Tu peux identifier les annonces avec beaucoup de profondeur de stock sur le UK. |
| Commentaire de Gaël Seguillon [ 16/mars/09 18:30 ] |
|
juste sur le JV ? merci Gael |
| Commentaire de Frédéric Nahum [ 18/mars/09 10:52 ] |
| JV ?? |
| Commentaire de Jérôme Viviès [ 18/mars/09 11:08 ] |
| Jeu Vidéo |
| Commentaire de Jérôme Viviès [ 18/mars/09 15:28 ] |
|
Gaël, Afin d'avoir un récap un peu construit : a/ Comme le signale Fred : ce qui est vu dans le BO est le nombre d'articles (=annonces x quantité) b/ Il n'est pas exact de dire qu'aucun pro n'a fait de l'import sur les différentes catégories sur les jours observés. Mais plutôt : - aucun nouveau pro n'est arrivé par import ce jour là. - les pros existant ont fait des mises à jour de leur stock, qui peuvent être conséquentes - comme l'indiquait Fred, il suffit de 70 annonces à quantité 100 pour que les chiffres bondissent. Exemple : passage à 78.000 articles jeux vidéo le 12 mars = import inandout (notamment) de 15000 articles (2800 annonce * quantité 3 + 900 annonces * quantité 8) c/ Nous avons une alerte mail qui nous informe des grosses variations de stock, mais n'avons pas d'outil qui permette d'identifier les pros ou de lister les pros par « profondeur de stock » (classement par nombre d'annonces ou d'articles) - mais peut-être est-ce faisable dans Business Object ? Nous essayons parfois d'expliquer les variations, mais vu le manque d'outil, ce n'est pas systématique aujourd'hui. En gros nous devons fouiller dans le back-office dans le détail des fichiers traités ce jour là... Conclusion : - Les chiffres du BO son fiables et reflètent des vrais mouvements de stock initiés par les pros. - Si vous avez un doute ponctuel => JIRA, comme tu as fait. - Si vous avez besoin de l'info systématiquement, on peut en parler, et aussi à PKR et JZ afin qu'on déclenche un projet là-dessus. Et / ou si vous voyez un moyen de produire un rapport BI... pourquoi pas ? - nous serions preneurs (!) |
| Commentaire de Gaël Seguillon [ 18/mars/09 15:43 ] |
|
ok merci je vais voir ce que l'on peut avoir via le BI mais pour l'instant le BI UK n'existe pas encore... C'est rassurant de savoir que les données tableau bord BI UK sont fiables. on a beacuoup de stock jeux qui est arrivé de pros qui n'étaient pas censés en vendre, je suis aller voir le stock de Inandout et il a effectivement du stock en JV ainsi que d'autres vendeurs qui étaient spécialisés musique, c'est la diversification de pros existants qui a généré cette montée rapide du nombre de références. |
[BIN-586] [Marketing] : Nouveau rapport de suivi des ventes effectives par tracking Création: 28/mai/09 13:12 Mise à jour: 28/janv./10 13:26 Résolue: 30/oct./09 15:07 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | CRM |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Ghislain Gridel | Attribution: | Julien Girardet |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
BRIEF+NOUVEAU8RAPPORT+SUR+LA+VENTEv1.doc
DMR - Rapport Daily item
followup by advert tracking and product family v1.0.docx
Maquette.xls
|
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Dans la continuité du rapport sur les mises en vente, et toujours dans l'objectif de suivre et analyser les résultats sur la vente par canal marketing (voir premier brief), nous aurions besoin d'un rapport sur les ventes effectives. --> Objectifs Actuellement, les ventes effectives ne sont pas suivies par canal en last tracking 30 jours. Les équipes Acquisition et Fidélisation ont de forts objectifs en recrutement de nouveaux vendeurs en 2009. Ces objectifs sont quantitatifs et qualitatifs. Nous souhaitons pouvoir mesurer, quantifier et qualifier l'acquisition des nouveaux vendeurs, aussi bien à partir du trafic venant de nos partenaires, que des actions mises en place part l'équipe fidélisation : Newsletter vente, CRM et opérations diverses. Nous aurions besoin de la mise en place d'un rapport spécifique sur les ventes effectives. Le brief est ci-joint. j'aimerai discuter avec vous pour voir ce qu'on met dans le volume d 'affaire/commission capturé/autorisé. Merci A votre dispo. Ghislain |
| Commentaires |
| Commentaire de Dalila Belkebir [ 30/sept./09 17:28 ] |
|
Ghislain, Voici ce que nous avions vu ensemble lors d'un point le 22/09 : Sur ce reporting, la notion de 1ère vente effective nécessiterait une évolution technique couteuse que nous ne pourrons mettre en place que si cette notion est susceptible d'être utilisée pour d'autres besoins. Il faut donc d'abord nous préciser ces autres besoins afin que nous puissions analyser au mieux la solution technique à mettre en place (et optimiser son coût de mise en place). En attendant cette analyse, je te propose de développer le rapport sans cette notion. Cette notion pourra alors être développé ultérieurement. Lors de la réunion BI MKT de lundi 28/09, Odile m'a signifié son accord pour un développement en 2 phases : - lot1 : sur Q4 2009 le Tdb sans la notion de première vente effective - lot2 : à planifier sur 2010, l'ajout de la notion de première vente effective, après étude des besoins associés Pourrais tu STP me le valider afin que je puisse lancer les spécifications et les développements associés ? merci. Dalila. |
| Commentaire de Ghislain Gridel [ 30/sept./09 18:15 ] |
|
Salut dalila, ok pour 2 lots. nous prenons en compte cela pour nos budgets. |
| Commentaire de Julien Girardet [ 07/oct./09 14:37 ] |
|
Salut Ghislain, Ci joint la maquette que nous avons validé hier. j'attends ton retour sur le type produit. Actuellement le rapport est uniquement sur le type de produit. Merci. Julien. |
| Commentaire de Julien Girardet [ 07/oct./09 14:38 ] |
|
correction : Actuellement le rapport est uniquement sur la FAMILLE de produit. Julien. |
| Commentaire de Ghislain Gridel [ 07/oct./09 17:26 ] |
| Après discussion avec thomas, il faut rajouter le type de produit. Merci |
| Commentaire de Julien Girardet [ 13/oct./09 12:17 ] |
|
Ghislain, voici les specifications du rapport. En attente de ta validation. Ainsi nous pourrons commencer les developpements. Merci Julien |
| Commentaire de Ghislain Gridel [ 13/oct./09 17:48 ] |
| ok pour moi. Merci |
| Commentaire de Dalila Belkebir [ 30/oct./09 15:07 ] |
|
Bonjour, Le nouveau rapport suivant a été livré en production dans ITEM : Daily item follow up by advert tracking and product family Merci de vos retours pour validation. Cdlt, Dalila. |
| Commentaire de Dalila Belkebir [ 28/janv./10 13:26 ] |
|
Odile, Comme vu avec toi en point MKT BI du 18/01/2010, cette demande est OK. Cdlt, Dalila. |
[BIN-636] [Marketing] : Extract cible pour op mailing postal Colissimo_PriceMinister Création: 23/nov./09 11:20 Mise à jour: 26/janv./10 17:37 Résolue: 30/nov./09 16:39 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Partners |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Charlotte Fachan | Attribution: | Julien Girardet |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Salut Dalila, nous allons (re)mettre en place une opération cobrandée avec colissimo.fr, du 25/12 au 30/01, sur le thème de la revente des cadeaux de Noël,en reprenant le dispositif mis en place dans le cadre de l'opération de septembre. Ainsi nous avons prévu d'envoyer un mailing postal sur 3 cibles distinctes : Cible 1 : clients ayant déjà utilisé le service (op sept / oct) => soit une estimation de 3 000 clients Cible 2 : Clients vendeurs PriceMinister avec adresses nettoyées (dédoublonnées du fichier du mailing de sept/ oct et des clients ayant bénéficié de l'offre) => soit une estimation d'environ 25 000 clients Cible 3 : Client base colissimo.fr (dédoublonnés du fichier du mailing de septembre / octobre et des clients ayant bénéficié de l'offre des 3¿)=> soit une estimation d'environ 22 000 clients Pour ce faire, j'aurais besoin d'un extract pour la cible 2 Vendeurs particuliers hors cobrandé ayant réalisé au moins 2 ventes, pas de blacklist, pas de fraudeur, pas de claims, avec adresse postale de paiement en France. Avec les champs suivants : - Id user - Civilité - Nom - Prénom - Adresse - Code postal - ville est-il également possible d'avoir un classement par adresses email invalides? avez -vous cette info? L'extract sera ensuite envoyé à PNDATA pour un redressement des adresses postales. Il faudrait donc prévoir un stock de 40 000 contact. Il me faudrait cet extract pour le 30/11 au plus tard. Merci Charlotte |
| Commentaires |
| Commentaire de Dalila Belkebir [ 24/nov./09 10:20 ] |
|
Bonjour Charlotte, Nous n'avons malheureusement pas l'info : "adresse email invalide". Nous ne pouvons donc pas te faire un classement sur la base de cette info. D'après ma première analyse l'extraction suivante me semble faisable par le BI : Vendeurs particuliers hors cobrandé ayant réalisé au moins 2 ventes, pas de blacklist, pas de fraudeur, pas de claims, avec adresse postale de paiement en France. Avec les champs suivants : - Id user / Civilité / Nom / Prénom / Adresse / Code postal / ville Cela me semble représenter une cible plus grande que 25 000 PMembers. As-tu une condition sur date ou bien souhaites-tu requêter sur l'ensemble des PriceMembers ? Ceci pourra être vu lorsque Julien fera la requête ainsi que son analyse de volumétrie. Je laisse Julien regarder cela d'un peu plus près et te faire part de ces éventuelles demandes de précision. Nous travaillons actuellement sur le projet Question/Réponses mais ton extraction pourra être faite d'ici le 30/11. Cordialement, Dalila. |
| Commentaire de Charlotte Fachan [ 24/nov./09 14:43 ] |
|
ok merci Dalila ! Passons nous du classement par "adresse email invalide". Effectivement le volume sera supérieur à 25 000 PMembers. Sachant que les adresses vont être ensuite redréssées par PN DATA il nous faut un volume bien supérieur pour être sûr dévoir 25 000 adresses "propres" au final. A ta dispo pour en parler. Charlotte |
| Commentaire de Julien Girardet [ 27/nov./09 11:28 ] |
|
Salut Charlotte, Avec les critères suivants, j'obtiens environ 100 000 users : - vendeurs particuliers - hors cob - ayant réalisés au moins 2 ventes cloturées depuis Janv 2009 - sans claim - pas fraudeur - ayant une adresse de paiement en France. Souhaites tu modifier la periode pour augmenter/diminuer la volumetrie ? Julien. |
| Commentaire de Charlotte Fachan [ 30/nov./09 10:25 ] |
|
Merci Julien, C'est parfait ! Partons sur ce volume. Peux tu m'envoyer l'extract ? Merci Charlotte |
| Commentaire de Julien Girardet [ 30/nov./09 16:39 ] |
|
L'extract est dispo ici : T:\BI\01 - Demandes ponctuelles\2009-12 Extract OP colissimo JIRA Julien. |
| Commentaire de Charlotte Fachan [ 30/nov./09 16:48 ] |
|
Super merci ! je transmets à PNDATA. Charlotte |
[EXP-1963] Gestion des adresses IP en interne pour les cobrnadings Création: 05/mai/06 15:36 Mise à jour: 25/juin/07 18:57 Résolue: 17/mai/06 12:42 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Sébastien Tournay | Attribution: | Jérémie Bennejean |
| Résolution: | Corrigé | ||
| Estimation restante: | 0 minutes | ||
| Temps consacré: | 2 heures, 50 minutes | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Une bonne façon d'économiser des adresses IP... Je viens de me rendre compte sur notre zone que nous avions une adresse IP par cobranding. En fait, ce n'est pas utile ;-)) On peut utiliser une seule adresse IP pour tous les cobrandings (ofup, m-.pm.lan..) puisque apache est configuré en virtualhost par nom. C'est le fonctionnement que nous avons en PROD. Je ne suis même pas certain qu'il soit utile d'avoir une @IP différente pour www.pm.lan bo.pm.lan comme nous l'avons en PROD. C'est surtout utile lorque le vont gérer des VIP pour la répartition de charge mais en INTEG.. pas besoin. Il faudrait donc faire du ménage dans les @IP pour en libérer et adapter la conf APACHE en conséquence. On devrait récupérer quelques adresses.. ATTENTION aussi à libérer les @IP virtuelle associées à la carte réseau de DEUTZ. |
| Commentaires |
| Commentaire de Pap Ndiaye [ 15/mai/06 13:56 ] |
| On prevoit cela en fin de semaine |
| Commentaire de Jérémie Bennejean [ 17/mai/06 12:41 ] |
|
C'est bon je m'en suis occupé. En résumé : 26 adresses IP ont été libérées sur les 31 cobrandings. 5 cobrandings ont conservés des @ IP: pm-es www bo preview bi Modification sur Deutz : httpd.conf Modification des virtuals hosts concernés --> pointent sur 192.168.1.90 restart et graceful de httpd /etc/sysconfig/network-scritp plutot que de supprimer les interfaces, je les ai renommé en .old au cas ou. redémarrage de la carte réseau Modification sur ruinart Zone DNS pm.lan.zone redémarrage du DNS Test de cobrandings liberation.pm.lan , m6.pm.lan, etc ... |
| Commentaire de Sébastien Tournay [ 17/mai/06 17:45 ] |
| Très bien. Il devient donc moins critique d'étendre la plage d'@IP. Peux tu nous l'inventaire des @IP que nous avons maintenant de dispo sur notre plage ? |
| Commentaire de Jérémie Bennejean [ 18/mai/06 10:59 ] |
|
Nous avons économisé 24 adresses IP La pluspart de cobrandings pointent sur 192.168.1.90 (ceux resté inschangés sont pm-es,liberation,www,bo,preview,bi,freesurf) Au total nous disposons sur la plage fixe (192.168.1.1-->192.168.1.99) de 56 adresses IP de libres ( rien que sur la plage fixe) |
[BIN-630] [Executive] Extract témoignages textes PriceMembers pour faciliter localisation de témoins RP Création: 29/sept./09 14:59 Mise à jour: 27/oct./09 10:02 Résolue: 07/oct./09 18:02 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Pierre Krings | Attribution: | Dalila Belkebir |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
PriceMinister est constamment sollicité par des journalistes
qui souhaitent faire un sujet sur PM mais ont besoin de vrais membres
pour témoigner de leur activité sur le site. Malgré (ou à cause) de la
taille de la base client, il n'est pas facile de trouver des candidats
potentiels susceptibles de parler de Price. L'idée est de faire une pré-sélection en se basant sur des membres qui ont pris la peinne de faire des témoignages écrits sur le site, à partir des formulaires "Mon histoire avec PriceMinister" et "Mon expérience avec PriceMinister". Il faudrait réaliser un extract de ces témoignages pouvant être visualisé dans excel, et associer des informations (sexe, age, géographie, acheteur / vendeur) susceptible d'aider à cibler. Basé sur le contenu du témoignage de la sélection, les membres pourront alors être contactés par téléphone. Infos requises : Login Sexe (si renseigné) Date de naissance (si renseignée) Date de création compte Nbre de ventes Nbre d'achats Type vendeur Date de dernière connexion Pays dernier achat (si renseigné) CP dernier achat (si renseigné) CP coordonnées vendeur (si renseigné) Date du message Titre du message Contenu du message Un extract one-shot pouvant être relancé de temps en temps semble suffisant. |
| Commentaires |
| Commentaire de Dalila Belkebir [ 07/oct./09 18:02 ] |
|
Bonjour Pierre, J'ai réalisé un extract avec les données que j'ai pu récupérées. Tu trouveras l'extract dans le répertoire : T:\BI\01 - Demandes ponctuelles\00 - Etudes PKR\Extraction des Members avec une Histoire avec PM Je n'ai pas inséré les données de type Nbre de ventes & Nbre d'achats car la requête a tourné sur TERRA afin d'obtenir le contenu du mail (non récupéré dans BI). J'y ai par contre inséré la note du vendeur afin de donner un avis sur la "qualité" du vendeur. Si tu souhaites vraiment ces infos je pourrais pousser un peu amis cela risque de me prendre du temps. Fais moi part de tes retours. Cdlt, Dalila. |
| Commentaire de Pierre Krings [ 07/oct./09 18:35 ] |
|
Merci. Bien compris sur le nbre d'achats et de ventes. Concernant la note du vendeur, il y a des très grandes valeurs. C'est le cumul des notes ? Dans ce cas, c'est parfait puisque ça renseigne sur la grosseur du vendeur plus que sur ça qualité, mais c'est très bien ! Il manque la date de naissance et le CP vendeur. C'est compliqué de les ajouter ? Le plus gros souci : les témoignages s'arrêtent à février 2006. Il n'y a que les messages qui ont pour titre "Dites-nous tout sur votre histoire avec PriceMinister". Ca vient peut-être de là. Idéalement, il faudrait tous les messages adressés à la boîte de messagerie "mktg ENQUETES". Et là on aura tout normalement. p |
| Commentaire de Dalila Belkebir [ 22/oct./09 11:37 ] |
|
Bonjour Pierre, J'ai sorti une nouvelle extraction de données sur la base des mails 'Dites-nous tout sur votre histoire avec PriceMinister', 'Mon expérience avec PriceMinister', 'Mon histoire avec PriceMinister' Tu la trouveras dans le répertoire : T:\BI\01 - Demandes ponctuelles\00 - Etudes PKR\Extraction des Members avec une Histoire avec PM N'hésite pas à nous communiquer tes retours ! Cdlt, Dalila. |
| Commentaire de Dalila Belkebir [ 27/oct./09 10:02 ] |
|
De : Pierre Krings [mailto:pierre.krings@priceminister.com] Envoyé : jeudi 22 octobre 2009 17:10 À : 'Dalila Belkebir (JIRA)' Objet : RE: [JIRA] Mise à jour: ( Ca a l'air bon. Merci ! Pierre Krings PriceMinister 57 Boulevard de la Villette F75010 Paris - France T: +33 (0)1 42 78 79 77 F: +33 (0)1 42 78 80 61 http://www.priceminister.com |
[APP-29252] Paniers capturés sans montant coupon capturé Création: 19/avr./10 14:29 Mise à jour: 04/mai/10 18:15 Résolue: 04/mai/10 15:28 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 66.0.1 |
| Version(s) corrigée(s): | 68.0.1 |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Julien Girardet | Attribution: | Arnaud Forgues |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
bug_APP-29252-cible-panier.xls
purchase_id.xls
PURCHASE_ID_280410.xlsx
|
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM: | *** RESERVE *** |
| Description |
|
Bonjour, Sur le mois d'Avril (04/2010), 47 paniers capturés ont un montant capturé < au montant total du panier. Ce sont des paniers avec coupons (secret name = FQPAF6, coupon_model_id = 696378), capturés mais avec un montant coupon capturé = 0. Nombre de paniers victimes du bug par jour : AUTHORIZATION_DATE COUNT(PURCHASE_ID) 03/04/2010 5 04/04/2010 18 05/04/2010 13 06/04/2010 4 07/04/2010 4 08/04/2010 2 09/04/2010 1 Ci-joint la liste des purchase_id victimes du bug (fichier excel). Julien. |
| Commentaires |
| Commentaire de Claire Durand [ 26/avr./10 12:05 ] |
|
Salut, encore des paniers en capture denied + coupon FQPAF6 Je croyais que ce pblème était réglé ? Pouvez vous me tenir au courant ? ex de panier récent : http://bo.priceminister.jmh/purchase_back?action=purchaseview&purchaseid=85604562 Merci Claire |
| Commentaire de Arnaud Forgues [ 26/avr./10 13:58 ] |
|
Non, le problème qui a été réglé est le fait que les paniers
qui doivent tomber en CAPTURE DENIED, ne le faisaient pas et du coup,
on ne pouvait pas identifier ce genre de problème là. Ici le souci est
lié au type de coupon (CRM_STANDARD) et le fait : - qu'il inclus les FdP dans la réduction - que sa politique d'annulation soit CANCELCASE_STANDARD et non CANCELCASE_NICE Ces 2 critères de stratégie coupon ne sont pas compatible car pour les coupons avec une politique d'annulation CANCELCASE_STANDARD, on annule un coupon lors de sa capture en vérifiant si la somme des montants des articles (hors FdP, CBV et EG) est inférieur au montant du coupon, ce qui peut etre le cas, sin on a des FdP élevé. Cela ne s'était pas produit auparavant car cette politique d'annulation était toujours couplées avec une statégie coupon d'exlusion des FdP, hors depuis peu (projet WS Coupon lot 2 livré en TX-M) les coupons CRM_STANDARD et CRM_FIRST_COUPON possèdent ces 2 critères de statégie. 2 solutions possibles pour résoudre le problème : - appliquer une politique d'annulation CANCELCASE_NICE aux types de coupons CRM_STANDARD et CRM_FIRST_COUPON - corriger la règle CANCELCASE_STANDARD pour qu'elles prennent en compte l'inclusion/exclusion des FdP (+ pareil pour CBV et EG) D'autre part, il faudra corriger les 47 cas identifiés par le BI + les nouveaux dont Claire parle. NB : le bug reste tout de même assez peu fréquent car il faut regrouper pas mal de facteurs : coupon d'un des 2 types sus-cités, avec un montant minimum au double du montant de la réduction (ce qui est le cas pour FQPAF6 : 12 euros pour 6 euros de réduction) ou pas beaucoup plus, et enfin un montant d'articles inférieur à 6 euros mais dont les FdP sont suffisamment élevés (donc plus de 6 euros) pour qu'on dépasse les 12 euros et que le coupon soit accepté ! |
| Commentaire de Claire Durand [ 26/avr./10 15:29 ] |
| Merci pour ta réponse Arnaud. Concernant tes 2 solutions, qui est sensé pouvoir prendre une décision ? Steven ? |
| Commentaire de Steven Harel [ 27/avr./10 09:07 ] |
|
C'est plutôt le marketing qui gère ce genre de choses. |
| Commentaire de Emeric Teil [ 27/avr./10 10:15 ] |
|
Hello, j'en ai déjà parlé avec eux hier, le souci c'est qu'Odile n'est pas là et que l'impact de cette décision concerne plutôt le budget donc... |
| Commentaire de Cédric Goldovsky [ 27/avr./10 11:07 ] |
| il faudrait préciser une nouvelle version cible |
| Commentaire de Julien Girardet [ 27/avr./10 18:31 ] |
|
Pour info, le bug continue. On en est à 58 paniers victimes du bug, toujours avec coupon (secret name = FQPAF6, coupon_model_id = 696378) Nombre de paniers victimes du bug par jour : AUTHORIZATION_DATE COUNT 03/04/2010 5 04/04/2010 18 05/04/2010 13 06/04/2010 4 07/04/2010 4 08/04/2010 2 09/04/2010 1 10/04/2010 2 11/04/2010 2 12/04/2010 2 13/04/2010 1 16/04/2010 1 17/04/2010 1 19/04/2010 2 |
| Commentaire de Julien Girardet [ 28/avr./10 11:07 ] |
| Purchase_id victimes du bug sur 04/2010 jusqu'au 28/04/2010 |
| Commentaire de Arnaud Forgues [ 30/avr./10 15:31 ] |
|
Concernant la correction applicative, Emeric a vu et validé
avec PKR que l'on partait sur la 2e option : on adapte donc la règle
CANCELCASE_STANDARD afin qu'elle prenne en compte l'inclusion (ou non)
des FdP pour déclencher l'annulation du coupon lors de la capture et
ainsi éviter ce genre de bug. Pour l'historique, un script va traiter les 59 paniers(1 de plus : 85604562) actuels concernés en : - repassant l'état du coupon de CANCELLED à CAPTURED - affectant le bon montant au coupon capturé dans le panier (purchase.capture_coupon_amount) déduit à partir du montant total du panier (articles + FdP + CBV + EG) moins le montant déjà capturé + un petit évènement sur le panier pour garder une trace - supprimant (passage de OPEN à DELETED) le nouveau coupon CRM_STANDARD généré pour chaque utilisateur concernés suite à l'annulation malencontreuse du bon coupon (si celui-ci a déjà été utilisé, alors on ne fera rien à part logguer l'information) Le script est dans V:/Database/TX-N/dev/TX-N_ La cible et les montants ont été vérifiés avec le BI, ono va donc pouvoir lancer une premiere fois le script. Par la suite on pourra le relancer suite au déploiement de la correction applicative lors du patch V68.0.1 afin de traiter les derniers cas qui seront apparu entre temps. |
| Commentaire de Cédric Goldovsky [ 03/mai/10 10:41 ] |
|
Note pour l'integ : Panier de test KO : 81285338 (nom du coupon annulé et recréé : "APP29252") après script : vérifier la capture avec nouvelle appli : refaire le même achat avec un autre compte + même coupon & paiement PMV |
| Commentaire de Arnaud Forgues [ 03/mai/10 11:42 ] |
|
Le correctif applicatif est commité sur le tronc pour déploiement en V68_0_0 ou V68_0_1 (à l'integ et Manu de voir) Il ne reste donc plus qu'à passer le script de correction pour les 59 paniers en PROD (+ les autres qui aopparaitont d'ici le déploiement du correctif) [CAJ2010Q2TX] |
| Commentaire de Arnaud Forgues [ 03/mai/10 11:46 ] |
| Je réouvre le JIRA en attendant de pouvoir faire le commit :-) |
| Commentaire de Arnaud Forgues [ 04/mai/10 11:25 ] |
|
Le script a été passé en PROD et a corrigé les 62 paniers (3 nouveaux depuis hier) actuellement concernés. Voici la liste exhaustive (via les logs du scripts) : Updating purchase 84826000 and coupon 89653218 with an amount of 3.4 Deleting coupon 89881059 for user 19684994 Updating purchase 84794797 and coupon 89648869 with an amount of 6 Deleting coupon 89881024 for user 13276541 Updating purchase 84796285 and coupon 89131331 with an amount of 6 Deleting coupon 89881030 for user 20100697 Updating purchase 84799473 and coupon 89192993 with an amount of 6 Deleting coupon 89881033 for user 20321127 Updating purchase 84799751 and coupon 89378173 with an amount of 6 Deleting coupon 89881036 for user 19987873 Updating purchase 84800230 and coupon 89647579 with an amount of 6 Deleting coupon 89881041 for user 19750771 Updating purchase 84801368 and coupon 89648087 with an amount of 6 Deleting coupon 89881040 for user 16553949 Updating purchase 84802221 and coupon 89332071 with an amount of 6 Deleting coupon 89653581 for user 19349490 Updating purchase 84807938 and coupon 89651645 with an amount of 6 Deleting coupon 89881045 for user 14489811 Updating purchase 84811020 and coupon 89652216 with an amount of 6 Deleting coupon 89881051 for user 20360852 Updating purchase 84811064 and coupon 89021385 with an amount of 6 Deleting coupon 89881046 for user 18920037 Updating purchase 84811590 and coupon 89331372 with an amount of 6 Deleting coupon 89881049 for user 19339834 Updating purchase 84812029 and coupon 89652191 with an amount of 6 Deleting coupon 89881050 for user 19253633 Updating purchase 84814986 and coupon 89303493 with an amount of 6 Deleting coupon 89881053 for user 15361094 Updating purchase 84819330 and coupon 89369879 with an amount of 6 Deleting coupon 89881054 for user 19842833 Updating purchase 84823638 and coupon 89653197 with an amount of 6 Deleting coupon 89881057 for user 19704225 Updating purchase 84824784 and coupon 88917205 with an amount of 6 Deleting coupon 89881058 for user 17618106 Updating purchase 84826405 and coupon 89132786 with an amount of 6 Deleting coupon 89881060 for user 16204928 Updating purchase 84832481 and coupon 89653229 with an amount of 3.1 Deleting coupon 89881061 for user 18788070 Updating purchase 84833486 and coupon 89651420 with an amount of 6 Deleting coupon 89881063 for user 19710829 Updating purchase 84837016 and coupon 89669427 with an amount of 6 Deleting coupon 89881064 for user 1787006 Updating purchase 84843561 and coupon 89667352 with an amount of 6 Deleting coupon 89881066 for user 19943007 Updating purchase 84843661 and coupon 89669344 with an amount of 6 Deleting coupon 89881065 for user 20400503 Updating purchase 84845825 and coupon 89665613 with an amount of 6 Deleting coupon 89881068 for user 19536954 Updating purchase 84858001 and coupon 89680419 with an amount of 6 Deleting coupon 89881069 for user 20019235 Updating purchase 84863493 and coupon 89680659 with an amount of 6 Deleting coupon 89881071 for user 20426166 Updating purchase 84863606 and coupon 89309053 with an amount of 6 Deleting coupon 89881072 for user 18970668 Updating purchase 84867937 and coupon 89680449 with an amount of 6 Deleting coupon 89881074 for user 17851053 Updating purchase 84869263 and coupon 89112198 with an amount of 6 Deleting coupon 89881073 for user 19895024 Updating purchase 84877551 and coupon 89517274 with an amount of 6 Deleting coupon 89881075 for user 19809174 Updating purchase 84880934 and coupon 89168451 with an amount of 6 Deleting coupon 89881078 for user 20129021 Updating purchase 84881050 and coupon 89689503 with an amount of 6 Deleting coupon 89881079 for user 17084291 Updating purchase 84886145 and coupon 89689710 with an amount of 6 Deleting coupon 89881080 for user 18110420 Updating purchase 84888405 and coupon 89350311 with an amount of 6 Deleting coupon 89881081 for user 15975521 Updating purchase 84889761 and coupon 89680346 with an amount of 6 Deleting coupon 89881082 for user 20169600 Updating purchase 84892436 and coupon 89689642 with an amount of 6 Deleting coupon 89886501 for user 226131 Updating purchase 84893302 and coupon 89679840 with an amount of 6 Deleting coupon 89886502 for user 19632264 Updating purchase 84897334 and coupon 89704590 with an amount of 6 Deleting coupon 89886503 for user 16226954 Updating purchase 84919438 and coupon 89129385 with an amount of 6 Deleting coupon 89886504 for user 20100391 Updating purchase 84920518 and coupon 89285433 with an amount of 6 Deleting coupon 89886507 for user 18505874 Updating purchase 84935918 and coupon 89653404 with an amount of 6 Deleting coupon 89931599 for user 19840551 Updating purchase 84941658 and coupon 89751808 with an amount of 6 Deleting coupon 89931602 for user 20400908 Updating purchase 84945947 and coupon 89751296 with an amount of 6 Deleting coupon 89931603 for user 18202105 Updating purchase 84969516 and coupon 89649753 with an amount of 6 Deleting coupon 89931604 for user 18502626 Updating purchase 85009306 and coupon 88678460 with an amount of 6 Deleting coupon 89955807 for user 10121992 Updating purchase 85030157 and coupon 89808395 with an amount of 6 Deleting coupon 90687315 for user 20434360 Updating purchase 85059146 and coupon 89828803 with an amount of 6 Deleting coupon 90687316 for user 20221145 Updating purchase 85090331 and coupon 89840139 with an amount of 6 Deleting coupon 90755611 for user 14713038 Updating purchase 85107988 and coupon 89842600 with an amount of 6 Deleting coupon 90755612 for user 19489001 Updating purchase 85133381 and coupon 89114868 with an amount of 6 Deleting coupon 90755623 for user 19930376 Updating purchase 85135095 and coupon 89844968 with an amount of 6 Deleting coupon 90755614 for user 14648398 Updating purchase 85184573 and coupon 89879757 with an amount of 6 Deleting coupon 90755615 for user 20150745 Updating purchase 85186063 and coupon 89881996 with an amount of 6 Deleting coupon 90755617 for user 20428116 Updating purchase 85201891 and coupon 89882934 with an amount of 6 Deleting coupon 90786957 for user 18859928 Updating purchase 85371006 and coupon 89186035 with an amount of 6 Deleting coupon 90943289 for user 20254401 Updating purchase 85407565 and coupon 88895998 with an amount of 6 Deleting coupon 90807706 for user 17303952 Updating purchase 85478492 and coupon 90756619 with an amount of 6 Deleting coupon 90943290 for user 18719723 Updating purchase 85483594 and coupon 90756741 with an amount of .7 Deleting coupon 90848390 for user 17024745 Updating purchase 85604562 and coupon 90848545 with an amount of 6 Deleting coupon 91033726 for user 17751610 Updating purchase 85662617 and coupon 88739800 with an amount of 6 Deleting coupon 91054916 for user 14948018 Updating purchase 85728297 and coupon 88834346 with an amount of 6 Deleting coupon 91054917 for user 16622419 Updating purchase 86016108 and coupon 91083550 with an amount of 6 Deleting coupon 91137692 for user 19322422 Nb of purchase updated : 62 |
[BIN-643] SECOND EXTRACT Kdo fid vendeur (supplément femmes) Création: 05/janv./10 15:19 Mise à jour: 06/janv./10 11:05 Résolue: 06/janv./10 11:05 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Charlotte Fachan | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
RQT_2nd_extract.sql
|
| Pays: |
FRA - France
|
| Description |
|
Comme discuté ensemble, ci dessous les nouveaux critères de
ciblage pour réussir à trouver au minimum 1400 "fidèles vendeuses" Vendeurs particuliers - avec civilité Mlle ou Mme - ayant généré entre 70¿ et 90¿ de com nette - ayant réalisé au min 10 ventes - et dont l'année de la dernière vente est 2009 (26 523) Cet extract devra ensuite être redressé par PNDATA (jeudi). La volumétrie doit donc être assez conséquente (au moins deux fois supérieur au volume manquant initial). Ps : Merci de bien inclure les ID user dans les champs pour pn data a votre disp pour en parler. Charlotte |
| Commentaires |
| Commentaire de Cyril Tanneau [ 05/janv./10 16:01 ] |
|
Charlotte, j'ai regardé à nouveau la requête pour l'extract. En conservant le critère initial "entre 12 et 40 ventes confirmées" et en descendant la commission nette générée "entre 70 et 90 Euros", j'obtiens 4411 vendeuses (civilité Mlle ou Mme), ce qui correspond à 3 fois le nombre manquant de vendeuses. Du coup, après avoir redressé les adresses, le compte sera bon... Est-ce que cela te convient? Merci, Cyril |
| Commentaire de Charlotte Fachan [ 05/janv./10 16:34 ] |
|
super ! partons là dessus. Tu confirmes que tu as bien exclu du ciblage les critères du premier extract? Merci Charlotte |
| Commentaire de Cyril Tanneau [ 05/janv./10 18:28 ] |
|
Charlotte, l'extract Extract_2_vendeuses.xls est disponible dans le répertoire T:\BI\01 - Demandes ponctuelles\02 - Etudes Marketing\2009 10 Etude CFA extract_vendeurs_part nous avons bien: - les vendeurs particuliers enregistrant: - entre 12 et 40 ventes capturées (Bornes comprises) - généré une commission PM capturée net >=70 et <90 Euros - dernière vente capturée en 2009 - Femmes (melle ou Mme uniquement) Pas de risque de doublon avec l'ancien extract puisque nous avons une comm. nette capturée strictement supérieure à 90E. |
| Commentaire de Cyril Tanneau [ 05/janv./10 18:30 ] |
|
Charlotte, l'extract Extract_2_vendeuses.xls est disponible dans le répertoire T:\BI\01 - Demandes ponctuelles\02 - Etudes Marketing\2009 10 Etude CFA extract_vendeurs_part nous avons bien: - les vendeurs particuliers enregistrant: - entre 12 et 40 ventes capturées (Bornes comprises) - généré une commission PM capturée net >=70 et <90 Euros - dernière vente capturée en 2009 - Femmes (melle ou Mme uniquement) Pas de risque de doublon avec l'ancien extract puisque nous avons une comm. nette capturée strictement supérieure à 90E. Merci, Cyril |
| Commentaire de Charlotte Fachan [ 06/janv./10 10:48 ] |
|
Super ! merci Cyril Charlotte |
Installation du nouveau serveur destiné à FAST en intégration
(EXP-942)
|
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | Sébastien Tournay | Attribution: | Jérémie Bennejean |
| Résolution: | Corrigé | ||
| Estimation restante: | 0 minutes | ||
| Temps consacré: | 2 heures, 30 minutes | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Vu les mesures de PERF sur KRUG pour l'indexer, il nous manque de la CPU. Jérémie, Peux tu avoir avec DELL pour ajouter 2 CPU supplémentaire à KRUG. Est-ce possible sur le 2850 ? Sébastien |
| Commentaires |
| Commentaire de Jérémie Bennejean [ 10/févr./06 12:09 ] |
|
Imossible de mettre 4 cpu sur un chassis de 2850. Par contre c'est possible de mettre 2 proc bi-core. J'ai demandé a DELL de savoir si on peut intervertir 2 xeon mon core avec 2 xeon bi-core, j'attends une réponse. Devis 2850 bi-core fait et donné |
| Commentaire de Jérémie Bennejean [ 14/févr./06 11:17 ] |
|
Contact du support dell a ce sujet. J'aurai la réponse d'ici demain. Les points soulevé sont : peut - on intervertir des xeon mono-core avec des xeon bi-core . Le socket est il le meme. le voltage aussi? Le ventilateur ? la comptabilité de la carte mere ? |
| Commentaire de Jérémie Bennejean [ 14/févr./06 13:52 ] |
|
Monsieur bennejean, La cartemere que vous avez sur la machine est compatible avec les processeurs Xeon dual core (Paxville). Par contre le nouveau Xeon (paxville)a un radiateur qui est plus gros que sur les anciens Xeon , ce n'est pas le même modèle. De plus, une mise à jour du bios sera éventuellement nécessaire pour prendre en compte le dual core . Bonne journée _____________________________________________ From: Roux, Yannick Sent: Tuesday, February 14, 2006 11:26 AM To: 'jeremie.bennejean@priceminister.com' Subject: Information sur cartemere pe2850 -4SSG12J- case 512971208 |
| Commentaire de Jérémie Bennejean [ 15/févr./06 15:43 ] |
| j'ai demandé une devis au commercial DELL pour intervertir les 2 procs. |
| Commentaire de Jérémie Bennejean [ 17/févr./06 11:04 ] |
|
Intervertir 2 proc monocore avec des bicores est donc possible. Il faut intervertir les ventilateurs en meme temps du fait qu'il soit differents. Je ferme le jira du fait que l'achat de bicore n'est à l'ordre du jour. |
[BIN-243] extraction mails pros auto pour envoi news pro Création: 11/déc./06 16:00 Mise à jour: 14/sept./07 17:33 Echéance: 13/déc./06 00:00 Résolue: 12/déc./06 16:07 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Bloquant |
| Rapporteur: | Lorenzo Nuccio | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | 2 heures | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | 2 heures | ||
| Pays: |
FRA - France
|
| Description |
|
Hello Agathe, Je dois envoyer une news pro cette semaine, j'aurai donc besoin, comme les mois précédents, d'une extract des mails pros auto pour pouvoir faire mon envoi sur EMV. Deadline : mercredi soir. Merci ! |
| Commentaires |
| Commentaire de Agathe Remy [ 11/déc./06 17:32 ] |
|
François, Peux-tu voir si tu peux faire un rapport BI pour cet extract:-) Ainsi Lorenzo pourrait le rafraîchier quand il en a besoin. Merci:-) Agathe |
| Commentaire de François Le Lay [ 12/déc./06 16:07 ] |
| Le rapport est mis en place dans BI. |
[APP-15282] Affiliation Programme Vendeur :: Metatache Création: 23/févr./07 13:54 Mise à jour: 25/oct./07 14:33 Résolue: 27/juil./07 17:47 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Affiliation |
| Affecte la/les version(s): | ToDo |
| Version(s) corrigée(s): | 17.0.0 |
| Type: | Nouvelle fonctionnalité | Priorité: | Mineur |
| Rapporteur: | Richard Dubois | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Σ Estimation restante: | Non spécifié | Estimation restante: | Non spécifié |
| Σ Temps consacré: | Non spécifié | Temps consacré: | Non spécifié |
| Σ Estimation originale: | Non spécifié | Estimation originale: | Non spécifié |
| Pièces jointes: |
Brief_Affiliation_Programme_Vendeurv1.doc
specs_affiliation_vendeur.doc
|
||||||||||||||||||||||||||||||||||||||||
| Sous-tâches: |
|
||||||||||||||||||||||||||||||||||||||||
| Pays: |
FRA - France
|
||||||||||||||||||||||||||||||||||||||||
| Projets PM: | *** RESERVE *** |
| Commentaires |
| Commentaire de Quentin de Chivré [ 04/juil./07 17:38 ] |
| A fermer ? |
| Commentaire de Ghislain Gridel [ 04/juil./07 17:53 ] |
|
Les rapports BI sont prévus pour le 10 juillet. Ghislain |
| Commentaire de Emeric Teil [ 04/juil./07 18:03 ] |
| De notre côté, tout est OK. On passe donc la main au BI pour la fin de suivi de cette méta-tache. |
[BIN-658] [Avis] : Extract Inscrit au jeu concours avis Création: 01/mars/10 18:14 Mise à jour: 14/oct./10 15:37 Résolue: 02/mars/10 16:51 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | CRM |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Carole Visser | Attribution: | Julien Girardet |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
EXTRACT_REVIEW_GAME_0210.xlsx
RE Impacts Flux 1M CTN-O.msg
req_extract_review_game.sql
|
||||||||||||||||
| Liens des demandes: |
|
||||||||||||||||
| Pays: |
FRA - France
|
||||||||||||||||
| Description |
|
Bonjour, Pour le moment, 1000Mercis ne dispose pas des données concernant l'inscription au jeu concours permanent avis. Je dois cependant envoyer un email annonçant aux participants qu'ils n'ont pas gagné au jeu ce mois-ci. Serait -il possible de réaliser un extract des PriceMembers inscrits au jeu concours au mois de février. La newsletter devait être envoyée le 04/03. Quand pensez vous pouvoir me fournir l'extract? Merci d'avance Carole |
| Commentaires |
| Commentaire de Dalila Belkebir [ 02/mars/10 13:27 ] |
|
Julien, Peux-tu regarder cela ASAP pour Carole ? Merci. Cdlt, Dalila. |
| Commentaire de Carole Visser [ 02/mars/10 15:23 ] |
|
Julien, Est ce que tu penses pouvoir m'envoyer l'extract pour demain midi? Si non, je reporte l'envoi de la news. Merci Carole |
| Commentaire de Julien Girardet [ 02/mars/10 16:51 ] |
|
Comme vu avec Carole : - Les données d'inscriptions au jeu concours Avis n'étaient pas pévu dans le périmètre de maj des flux 1M Impacts CTN-0 (voir mail MKT en pj) - En pj l'extract des Users concernés par le tirage au sort du mois de Fevrier (j'ai vu les conditions du tirage au sort avec Renaud) A voir comment on procède pour les prochains mois. (L'ajout du "IS_REVIEW_GAME_PLAYER" dans le flux 1M n'est pas suffisant pour que 1M détermine si le User est concerné par le tirage au sort...) Julien. |
| Commentaire de Carole Visser [ 22/mars/10 12:20 ] |
|
Bonjour, Avez-vous pu avancer sur le sujet? Merci d'avance, Carole |
| Commentaire de Julien Girardet [ 22/mars/10 16:25 ] |
|
Bonjour, Si le mail doit être envoyé à tous les users concernés par le tirage au sort, alors la cible doit être calculée en synchro avec le tirage au sort. En effet, le tirage au sort prend en compte tous les users ayant déposés des avis dans le cadre du jeu ET étant inscrit au moment du tirage. Donc l'état d'inscription au jeu concours à l'instant t est important pour déterminer la cible. Si l'on veut envoyer les infos nécessaires à 1 M pour qu'il puisse déterminer la cible, il faudrait envoyer l'état d'inscription des users au jeu ainsi que les données concernant les avis déposés dans le cadre du jeu. De plus, il y a peu de chance que 1M génère la cible le même jour que le tirage au sort. Donc il y aura forcément un décalage... Donc je vois 2 solutions : - On intègre la génération de la cible au process du tirage au sort (A voir avec les Devs). La cible étant la meme que le tirage au sort. - On créée un rapport BI générant la cible (afin d'être envoyé à 1M) qui devra être lancé le même jour que le tirage au sort. Sachant que cette solution implique un cout niveau BI, car nous n'avons pas actuellement ces données dans notre DataWareHouse A votre dispo pour plus d'infos. Merci Julien. |
| Commentaire de Agathe Remy [ 24/mars/10 15:20 ] |
|
Carole, Pour avoir la liste des participants au jeu concours avis du mois M-1 au moment du tirage au sort depuis le BO, ça nous demande un peu de DEV. Est-ce que tu peux nous faire un JIRA à dispatcher-CTN qu'on traitera en réserve dès qu'un DEV aura de la dispo ? En attendant, tu pourras te baser sur l'équipe BI qui effectuera la requête à la mano (à faire en même temps que le tirage au sort pour être concordant). Agathe, je te mets en observatrice du JIRA pour que tu puisse nous transmettre la requête que vous avez déjà construite. Merci. Fabrice FEUGAS |
| Commentaire de Agathe Remy [ 14/oct./10 15:37 ] |
|
L'extract est à présent disponible en BackOffice : cf JIRA Agathe |
[BIN-677] TFV: SLTV par tracking de 1ère mev Création: 21/mai/10 14:32 Mise à jour: 08/nov./10 11:48 Résolue: 14/oct./10 15:38 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | CRM |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Audrey Angleys | Attribution: | Valéria Gusa |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
DMR -Seller lifetime by first advert tracking 10.docx
DMR -Seller lifetime by first advert tracking 11.docx
|
| Pays: |
FRA - France
|
| Description |
|
Bonjour,
Comme discuté, nous aurions besoin de développer un rapport "SLTV par tracking de 1ère mev". * Contexte: Recrutement des vendeurs en décroissance : -3% en avril 2010. On cherche donc à comprendre d'où provient cette décroissance, et à trouver quels canaux nous permettent de recruter de nouveaux vendeurs à fort potentiel. * Objectif: Piloter au mieux le budget vente en ayant connaissance de la valeur de nos vendeurs recrutés par canal d'acquisition. Au bout de combien de temps nos vendeurs transforment-ils leur mev en vente effective selon les différents canaux d'acquisition? Y a-t-il des différences importantes de taux de transfo selon les canaux ? Et surtout, combien nous rapporte un vendeur recruté via tel canal ? * Données à suivre dans le rapport : ¿ Mois de dépôt de la 1ère annonce (promo) [filtre] ¿ Mois considéré (activity month) [filtre] ¿ Groupe de tracking [filtre] ¿ Code de tracking [filtre] ¿ Nb de 1ères mev ¿ Nb de mev ¿ Nb de ventes effectives réalisées entre le mois de dépôt de la 1ère annonce et le mois considéré ¿ Somme de la com générée par les ventes effectives en question ¿ Taux de transfo : nb ventes effectives / (nb PMEV + nb MEV) => facultatif car je peux le calculer ensuite ¿ Valeur vendeur par tracking : Somme de la com/nb nouveaux vendeurs recrutés => facultatif car je peux le calculer ensuite Je reste à votre dispo pour en parler de vive voix. Merci d'avance! Audrey |
| Commentaires |
| Commentaire de Agathe Remy [ 22/sept./10 10:28 ] |
|
Bonjour Audrey,
Tu trouveras ci-joint les spécifications du rapport "SLTV by first advert tracking". Stp, peux-tu les valider d'ici le 27/09 afin que nous puissions lancer les dévs la semaine prochaine? Avec mes remerciements, Agathe |
| Commentaire de Agathe Remy [ 22/sept./10 10:33 ] |
|
Pour compléter la validation des spécifications, j'aurais quelques questions :
- faut-il ajouter le filtrage "tracking 30j"?, i.e. veux-tu que nous filtrions uniquement les promotions ayant déposé leur première annonce dans les 30 jours suivant le dépôt du coockie ? - Veux-tu qu'on ajoute un indicateur "délai moyen de vente" afin de répondre à ta question "Au bout de combien de temps nos vendeurs transforment-ils leur mev en vente effective selon les différents canaux d'acquisition?"? - Veux-tu nous fournir une liste des groupes de tracking pour lesquels tu voudrais l'historique? A ta dispo, Agathe |
| Commentaire de Audrey Angleys [ 23/sept./10 18:16 ] |
|
Bonjour Agathe,
Comme vu ensemble cet après-midi: - Oui pour le tracking 30j - Oui également pour rajouter le délai moyen de vente (merci!) - Pour les paramètres de dates, le but est d'établir un suivi (voir comment évolue la part des différents canaux) donc il faudrait en filtre le mois d'activité et que le rapport puisse sortir les actions de toutes les promos de vendeurs dans le mois. - Liste des groupes de trackings pour l'historique: => CRM Vente => priceletter-vente => Test Vente => LS-Google (un seul tracking nous intéresse dans celui là: LS-Google-sell) => Zanoxx (le tracking qui nous intéresse : Zanoxx-CarrefourInternet) => Affiliationx - Vendeur (celui qui nous intéresse: Affiliationx-Programme-Vendeur) Merci d'avance! A ta dispo pour en reparler, Audrey |
| Commentaire de Agathe Remy [ 29/sept./10 17:42 ] |
|
Corrections suite à la validation d'Audrey.
Agathe |
| Commentaire de Audrey Angleys [ 05/oct./10 15:55 ] |
|
Hello,
Juste pour info, pour quand prévoyez-vous la livraison de ce rapport? Merci ! Audrey |
| Commentaire de Valéria Gusa [ 05/oct./10 16:05 ] |
|
Bonjour,
Normalement, c'est prévu courant semaine prochaine. Valeria |
| Commentaire de Audrey Angleys [ 05/oct./10 16:09 ] |
| OK merci! |
| Commentaire de Valéria Gusa [ 14/oct./10 15:38 ] |
|
Bonjour,
Le rapport 'Seller lifetime value by first advert tracking' vient d'être livré en Production sur les plateformes FR, ES et UK (Dossier Seller). Merci de valider la fiche Jira afin que nous pussions la fermer. Valeria. |
| Commentaire de Valéria Gusa [ 14/oct./10 16:00 ] |
|
L'historique, pour les groupes de tracking demandés, est disponible dans le dossier suivant :
T:\BI\02 - Historiques de données\2010-10 Seller lifetime value by first advert tracking Valeria |
| Commentaire de Audrey Angleys [ 26/oct./10 16:21 ] |
|
Hello,
Pour l'historique des données, serait-il possible de le ressortir pour ce tracking "Affiliationx-EmaileurVendeurs" (dans le groupe de tracking "Affiliationx") svp ? Merci d'avance et désolée pour le contretemps. Audrey |
| Commentaire de Valéria Gusa [ 26/oct./10 17:11 ] |
|
Salut,
L'historique demandé a été généré dans le dossier T:\BI\02 - Historiques de données\2010-10 Seller lifetime value by first advert tracking Valeria |
| Commentaire de Audrey Angleys [ 26/oct./10 17:42 ] |
| Merci beaucoup! |
[BIN-561] [1Euro] : Ecart sur commission 1Euro.com Création: 26/févr./09 10:13 Mise à jour: 18/nov./10 18:07 |
|
| Etat: | Ouvert |
| Projet: | Business Intelligence |
| Composants: | CRM |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Charlotte Fachan | Attribution: | Julien Girardet |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Salut Agathe, comme convenu ensemble ci joint un petit topo sur le rapport qu'il me faudrait pour vérifier l'écart sur le commissionnement 1.com Chaque mois, 1¿.com nous transmet des infos sur le nombre de souscription au service générée par PriceMinister. Comme tu le sais nous sommes rémunérés 12¿ sur chaque nouveau clients apportés. J'ai cependant noté de gros écarts avec ce que nous facturons à 1¿.com (entre 17 et 20%) Il me faudrait donc un rapport sur le nombre de transactions par mois payées avec 1¿.com (pour la première fois) et le nombre de celles qui ont été annulées (de quelques manières que ce soit et qui n'ont pas donné lieu à une souscription) L'idéal serait d'avoir l'info par mois et sur 2007 et 2008 pour pouvoir comparer avec les données que j'ai de mon côté. Pour ton aide tu trouveras sous mon public les bilan 1¿ (onglet souscription) A ta dispo pour en parler Merci Charlotte |
| Commentaires |
| Commentaire de Charlotte Fachan [ 04/mars/09 09:10 ] |
|
Salut Agathe je reviens vers toi concernant cette demande. As tu besoin de plus d'infos là dessus pour avancer? A ta dispo pour en parler Merci Charlotte |
| Commentaire de Agathe Remy [ 04/mars/09 11:11 ] |
|
Bonjour Charlotte, Au cours de notre point bi-mensuel de lundi avec Odile et Thomas, ce JIRA a été défini en priorité 5. Il ne sera donc pas traité avant avril et nous reviendrons vers toi lorsque nous le traiterons. Je crois d'ailleurs qu'Odile voulait en discuter avec toi avant... Agathe |
| Commentaire de Thomas Beylot [ 10/mars/09 16:24 ] |
|
Hello en fait la conclusion du point bi-mensuel était plutôt que je regardais la demande de Charlotte afin de savoir si on pouvait le faire nous même. Si c'est le cas, pas de charge pour vous, sinon, on revient (avec odile) vers vous pour prioriser. Ce n'est pas tout à fait la même chose :) bref mais j'ai l'impression qu'on peut s'en sortir sans vous. Il suffit de se construire un rapport "transactions avec mode de paiement 1¿", plus statut du panier (cancelled etc) non ? thomas |
| Commentaire de Agathe Remy [ 10/sept./09 14:44 ] |
|
Bonjour Thomas, Des nouvelles de ce JIRA? Puis-je le clôturer? Merci:-) Agathe |
| Commentaire de Dalila Belkebir [ 04/janv./10 09:58 ] |
|
Bonjour Thomas, Des nouvelles de ce JIRA? Le besoin sera-t-il repris dans le projet libéralisation 1¿.com ? Puis-je le clôturer? Merci. Dalila. |
[CAT-3032] OP de collecte 2010 - import de contacts Création: 16/août/10 15:23 Mise à jour: 08/déc./10 10:05 Résolue: 08/déc./10 10:05 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Non Import |
| Composants: | Import de contacts Marketing |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Carole Visser | Attribution: | Carole Boucheny |
| Résolution: | Corrigé | ||
| Σ Estimation restante: | Non spécifié | Estimation restante: | Non spécifié |
| Σ Temps consacré: | Non spécifié | Temps consacré: | Non spécifié |
| Σ Estimation originale: | Non spécifié | Estimation originale: | Non spécifié |
| Pièces jointes: |
Codes_provenance_PM.xlsx
Codes_provenance_PM2.xlsx
Nouveaux_Contacts_Affiliation_18102010.xlsx
resultat_18-10-2010.csv
|
|||||||||||||||
| Sous-tâches: |
|
|||||||||||||||
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Comme chaque année, nous allons mettre en place mi-septembre une nouvelle opération de collecte d'adresses. Jusqu'à présent, ce type d'opérations était réalisé avec 1000Mercis. Nous avons choisi cette année de faire appel à une nouvelle agence La Fabrique à Jeux. Cependant, contrairement à 1000Mercis, cette nouvelle agence ne dispose pas de notre base de données et ne pourra donc pas réaliser seule la déduplication. Cela pose un problème au niveau du suivi de l'opération et au niveau de l'affiliation. Pour remédier à ce problème, l'agence nous fournira chaque semaine la liste des inscrits à l'opération. Nous devrons donc effectuer la déduplication avec notre base avant de les intégrer. Je pourrais dans ce cas renvoyer à l'agence et à la plateforme d'affiliation la liste des adresses non présentes dans notre base en fonction d' idfrom. A votre dispo pour toute question complémentaire, Carole |
| Commentaires |
| Commentaire de Fotigui Tangara [ 16/août/10 15:30 ] |
| Demande destinée plutôt au pôle CAT ? |
| Commentaire de Jérôme Viviès [ 20/août/10 10:22 ] |
|
Carole (V), et Clémence, Petite remarque en passant : tous les jiras que vous ouvrez au param doivent être des JIRAs "Param non import" (CAT) - les jiras "Param import" (IMP) sont destinés à l'équipe qui s'occupe de l'importation des fichiers de stocks des vendeurs pro - rien à voir. Et il faut systématiquement mettre Carole Boucheny en observatrice des demandes flux / import de contacts - je ne sais pas si le mot est bien passé. M E R C I D E T R A N S M E T T R E A V O S C O L L E G U E S :))))) |
| Commentaire de Carole Boucheny [ 09/sept./10 16:44 ] |
|
Bonjour,
Voici les informations sur le ftp à transmettre au partenaire : Host : ftp.priceminister.com Login : market Password :m!2010PM Le partenaire devra donc déposer ses fichiers à la racine. Carole, peux-tu me confirmer la structure qu'auront les fichiers fournis. Merci |
| Commentaire de Carole Boucheny [ 10/sept./10 17:08 ] |
|
Le script de mapping a été adapté sur hercule "market.pl".
Carole peux-tu aussi m'envoyer les correspondances entre les idfrom et les codes tracking. Merci |
| Commentaire de Carole Boucheny [ 10/sept./10 17:14 ] |
| (Adaptation du script market.sh) |
| Commentaire de Carole Boucheny [ 14/sept./10 15:34 ] |
|
Les fichiers seront déposé à la racine.
Les extracts seront au format csv avec des « ; » comme séparateur. L’ordre des champs : Email ; nom ; prénom ; civilité ; idfrom ; optin |
| Commentaire de Carole Visser [ 14/sept./10 17:19 ] |
|
En PJ le tableau de correspondance qui sera complété au fur et à mesure
|
| Commentaire de Carole Visser [ 14/sept./10 17:29 ] |
|
Il y avait une erreur dans le premier fichier.
Il faut utiliser le PM2 |
| Commentaire de Carole Boucheny [ 27/sept./10 11:43 ] |
|
Bonjour,
J'ai mis en place les mapping avec le tableau fourni. Quel est le code tracking par défaut pour les cas qui n'ont pas encore été défini ? Merci |
| Commentaire de Carole Boucheny [ 04/oct./10 10:54 ] |
|
Bonjour,
Je n'ai pas de nouvelle pour cette demande. Pouvez-vous me fournir un code tracking par défaut ? Avez-vous déjà reçu un fichier d'import de contact à faire ? Merci |
| Commentaire de Carole Visser [ 04/oct./10 12:32 ] |
|
Bonjour Carole,
Si je comprends bien ta demande, il y aurait des nouveaux contacts sans code de provenance. Ce n'est pas normal. Combien d'individus cela représente t-il? Merci Carole |
| Commentaire de Carole Boucheny [ 04/oct./10 13:54 ] |
|
Salut,
Je n'avais pas vu que deux fichiers ont déjà été déposé. Ce que je disais pour les codes tracking c'est qu'il est bien de mettre un code par défaut au cas où le code de provenance n'aurait pas été prévu. Merci |
| Commentaire de Carole Visser [ 04/oct./10 15:46 ] |
|
Carole,
Voici le first tracking à utiliser pour les individus dont le code de provenance n'est pas défini : 2317440 Comme vu ensemble, il faudrait compléter les fichiers d'extract en indiquant pour chaque individu s'il était déjà présent dans la base PM ou non. A ta dispo si tu as des questions. Carole |
| Commentaire de Carole Boucheny [ 04/oct./10 16:31 ] |
|
J'ai mis le code tracking par défaut.
Par contre, j'ai regardé de plus près pour savoir si chaque individu était nouveau ou non. Je ne peux pas avoir cette information. Les logs du batch d'import n'étant pas assez détaillé. Je ne peux que faire un comptage. L'autre solution serait d'extraire de la base (par requête sql) les emails des contacts avec les codes first tracking listé. Ceci veut dire qu'on ne listera que les nouveaux conctacts avec leur provenance. Est-ce que cette solution pourrait aller ? Merci Carole |
| Commentaire de Carole Visser [ 05/oct./10 17:15 ] |
|
Carole,
Comme vu ensemble, ok pour la deuxième solution. Il faudrait que tu m'envoies chaque semaine la liste des nouveaux contacts avec leur first tracking et leur adresse email. Pour le moment, il y a un problème avec les fichiers présents sur le ftp. Je te fais signe dès que c'est résolu. Carole |
| Commentaire de Carole Visser [ 06/oct./10 10:29 ] |
|
Bonjour Carole,
Tu peux maintenant utiliser le nouvel fichier déposé par La Fabrique à Jeux sur le ftp (celui du 05/10). Ce fichier regroupe les 2 précédents ainsi que les individus manquants. A ta dispo si tu as des questions, Carole |
| Commentaire de Carole Visser [ 08/oct./10 11:17 ] |
|
Bonjour Carole,
As tu pu avancer sur l'intégration et la dédup des premiers extract? Merci Carole |
| Commentaire de Carole Visser [ 14/oct./10 11:59 ] |
|
Carole, je n'ai pas eu de retour de ta part à ce sujet.
|
| Commentaire de Carole Boucheny [ 15/oct./10 17:10 ] |
|
Carole,
Peux-tu me confirmer que pour les provenances à partir de "PRMI015" suivantes le code tracking est vide ou est-ce que je dois mettre le code tracking par défaut (2317440 ) ? Merci Carole |
| Commentaire de Carole Visser [ 15/oct./10 17:16 ] |
|
Carole,
Normalement tu dois avoir très peu de provenances "PRMI015", moins de 5. Si ce n'est pas le cas, c'est qu'il y a un problème. Pour ce code de provenance, il faut utiliser le code de tracking : 2314243 Merci Carole |
| Commentaire de Carole Boucheny [ 15/oct./10 17:38 ] |
|
Oui, il n'y en a pas beaucoup mais j'avais un doute car à
partir de PRMI015 il n'y a pas de valeur correspondante. Est-ce que pour
les suivantes c'est aussi 2314243 ? Dans ce cas, peux-tu mettre à jour
le fichier joint.
Par contre, il y en a beaucoup plus de provenance "MSPONR". Pour celle-ci j'utilise aussi le code de tracking par défaut ? Merci |
| Commentaire de Carole Visser [ 15/oct./10 17:47 ] |
|
Pour le code de provenance MSPONR, il faut utilisé le code de tracking 2314242
Normalement, il ne doit pas y avoir d'individu avec des codes de provenance supérieur à PRMI015 |
| Commentaire de Carole Boucheny [ 18/oct./10 16:42 ] |
|
Le premier import a pu être lancé.
Demain, nous pourrons donc connaître les nouveaux contacts. Comme vu ensemble : _ créer un fichier csv avec les informations suivantes pour les nouveaux contacts : id, mail, code tracking _ il faut créer un ftp pour que les affiliés puissent récupérer ces fichiers. |
| Commentaire de Carole Visser [ 18/oct./10 16:54 ] |
|
Il s'agit du code de provenance et non du code de tracking.
Le code de provenance est présent dans l'extract fourni par la fabrique à
jeux.
C'est la même chose pour l'id, il est présent dans l'extract. Est ce que tu pourrais m'envoyer le fichier avec l'ensemble des nouveaux contacts et ne déposer sur le nouveau ftp que les contacts avec les codes de provenance PRMI011 et PRMI012? Merci Carole |
| Commentaire de Carole Boucheny [ 18/oct./10 16:55 ] |
|
J'ai créer le compte ftp suivant :
login : market_affiliation mdp : market!AffiliationPM |
| Commentaire de Carole Boucheny [ 18/oct./10 16:57 ] |
| (Le Host est toujours ftp.priceminister.com) |
| Commentaire de Carole Boucheny [ 18/oct./10 17:07 ] |
|
Ok c'est noté. Je pourrais t'envoyer cela demain matin. (Attention ceci sera pour le fichier du 05).
Demain je ferais l'import pour le 11 et du 18. Donc Mercredi nous serons à jour. Les semaines suivantes, je ferais l'import tous les lundis. Tu auras donc le fichiers des nouveaux contacts le mercredi. |
| Commentaire de Carole Visser [ 18/oct./10 17:10 ] |
|
Il me le faudrait vraiment sur le dernier import car c'est celui qui contient les donner sur l'affiliation.
Il regroupe tous les inscrits depuis le début du jeu, ça ne sert à rien de le faire sur les 3. |
| Commentaire de Carole Boucheny [ 19/oct./10 10:07 ] |
|
Bonjour,
Si j'importe uniquement le fichier du 18 c'est bon, c'est cela ?? Merci Carole |
| Commentaire de Carole Visser [ 19/oct./10 10:14 ] |
|
Oui c'est ça.
Il regroupe l'ensemble des inscrits depuis le début du jeu |
| Commentaire de Carole Boucheny [ 19/oct./10 13:34 ] |
|
Le batch d'import de contact lancé hier par l'exploit a
généré des erreurs. Je dois donc regarder ce qui provoque cela et le
corriger avant de pouvoir importer les contacts de lundi.
Je te tiens au courant et règle ce problème au plus vite pour qu'on puisse avoir la liste des nouveaux contacts au plus tard demain. Merci Carole |
| Commentaire de Carole Boucheny [ 19/oct./10 13:50 ] |
| Le problème est résolu. L'exploit relancera le batch dans l'après-midi. |
| Commentaire de Carole Visser [ 20/oct./10 14:12 ] |
|
Bonjour Carole,
Où en es tu avec la dédup des inscrits à l'OP de collecte? Il faut absolument que je fournisse les chiffres à la plateforme d'affiliation aujourd'hui. Merci Carole |
| Commentaire de Carole Boucheny [ 20/oct./10 14:16 ] |
| L'exploit n'a pas pu lancer le batch ce matin, ils l'ont lancé aujourd'hui. Du coup, les dba sont en train d'exécuter la requête que je leur ai donné directement en prod. Tu auras le fichier aujourd'hui. |
| Commentaire de Carole Boucheny [ 20/oct./10 15:32 ] |
|
Ci-joint le fichier avec l'email, le code de provenance et l'id.
Je l'ai aussi déposé sur le ftp market_affiliation. |
| Commentaire de Carole Visser [ 21/oct./10 11:10 ] |
|
Merci Carole.
Sur le ftp market_affiliation, il fallait déposer un fichier avec uniquement les nouveaux contacts avec les codes de provenance PRMI011 et PRMI012. |
| Commentaire de Carole Visser [ 21/oct./10 11:13 ] |
|
Carole,
Tu trouveras en pièce jointe le nouveau fichier avec seulement les codes de provenance PRMI011 et PRMI012 à déposer dès que possible sur le ftp market_affiliation. Merci Carole |
| Commentaire de Carole Visser [ 21/oct./10 11:16 ] |
|
Carole,
Dis moi dès que c'est fait pour que je prévienne la plateforme d'affiliation. Merci |
| Commentaire de Carole Visser [ 21/oct./10 11:43 ] |
|
Je suis désolée de te relancer mais il faut vraiment que ce fichier soit sur le ftp avant midi.
Merci carole |
| Commentaire de Carole Boucheny [ 21/oct./10 12:08 ] |
| Le fichier est déposé sur le ftp |
| Commentaire de Carole Boucheny [ 25/oct./10 10:44 ] |
|
Bonjour,
J'ai récupéré le fichier de ce matin. Le batch sera lancé par l'exploit dans la journée. Nous pourrons donc avoir les résultats des nouveaux inscrits demain matin. Carole |
| Commentaire de Carole Visser [ 26/oct./10 17:50 ] |
|
Carole,
La fabrique à jeux vient de déposer un nouveau fichier sur le ftp en ajoutant une colonne partenaire. Pour être plus clair, il y a 2 choix pour la colonne "'optin" Non: Optout Oui : Optin PriceMinister Pour la colonne "partenaire", 2 choix: Non: Pas optin partenaire Oui : Optin partenaire Comme vu ensemble, il faut donc mettre à jour ces infos pour les nouveaux contacts et les inscrits déjà en base. Pour les inscrits déjà en base, il ne soit s'agir que d'upgrade, c'est à dire que si la personne est optin partenaire en base et a coché seulement optin dans le jeu, on conserve le statut d'optin partenaire. A ta dispo si tu as des questions. carole |
| Commentaire de Carole Visser [ 26/oct./10 19:09 ] |
|
Carole,
Comme vu ensemble, est ce que tu pourrais modifier le fichier déposé sur le ftp destiné à la plateforme d'affiliation en supprimant les individus qui ne sont pas optin? Merci Carole |
| Commentaire de Carole Visser [ 27/oct./10 11:26 ] |
|
Bonjour Carole,
Est ce que tu as pu avancer sur le nouveau fichier pour la plateforme d'affiliation? J'ai vraiment besoin de ce fichier rapidement pour prendre des décisions sur la suite de la campagne. Merci Carole |
| Commentaire de Carole Boucheny [ 27/oct./10 14:05 ] |
|
Salut Carole,
Le fait que le partenaire n'ai pas fourni dès le départ un fichier dans un format correspondant au formulaire du jeu nous a induit en erreur et les imports de contacts se sont mal faits. Voici le mail envoyé aux équipes techniques afin de rechercher une solution à ce problème : Bonjour, Suite au "Grand jeu concours" (opé "collecte"), plusieurs imports de contacts ont eu lieu sur le site France (https://priceminister.onjira.com/browse/CAT-3032). Cependant, à cause d'une mauvaise compréhension avec le partenaire qui nous fournit les fichiers, les abonnements aux newsletters ne sont pas corrects. Des gens ont donc été abonnés par erreur aux newsletters PM ou PM + partenaires. Nous devons trouver rapidement une solution afin de corriger la situation. => Merci de regarder ce qui est proposé plus bas et de donner votre avis. 1/ ANALYSE DU PROBLEME Jusqu'à présent le partenaire remplissait une colonne par Oui ou Non. Cette colonne était interprétée comme cela de notre côté : Si Oui --> Abonnement aux newletters Price et Partenaire Si Non --> Abonnement aux newletters Price La colonne Oui et Non actuelle correspond en fait à : Oui --> Abonnement aux newletters Price Non --> Aucun abonnement Nous avons donc abonnement : - de personnes à la NL PM, alors qu'elles n'auraient pas dû l'être. - de personnes à la NL PM + partenaires alors qu'elles auraient dû être abonnées seulement à la NL PM. De plus, nous avons en fait 3 cas d'abonnements possibles dans ce jeu : - Abonnement aux newletters Price - Abonnement aux newletters Price et Partenaire - Aucun abonnement 2/ SOLUTION - COTE PRICE => Le partenaire doit nous refournir l'ensemble des contacts à importer, avec une nouvelle colonne pour les Abonnements Partenaire => Avant cela, il faudrait pouvoir désabonner tous les contacts qui ont été créés par ce jeux. Voici les actions qui permettraient de remettre le maximum de choses à plat. A --> Supprimer tous les contacts de la table temporaire de mise à jour de contact (seul le batch d'import de nouveau contact a tourné). B --> Supprimer les contacts qui n'ont pas encore donné lieu à création de compte. C --> Désabonner les contacts qui se sont créés un compte. Implémentation : A --> requête sur la base B --> ? difficile à faire en SQL ? - Utiliser une moulinette qui simulerait le clic sur le bouton "Fermeture" du compte (en BO) ? C--> Idem _ Utiliser la même moulinette mais avec l'url du bouton "Tout désabonner". Ces deux dernières actions envoient un mail au contact. Il faudrait donc modifier l'adresse email avant de le faire. Ceci ne pose pas de problème lorsque les comptes seront fermés. Par contre c'est plus délicat lorsque pour désabonner tous les contacts qui ont un compte Price. Tout le monde est-il d'accord avec cette analyse ou qqn voit-il une autre façon de faire ? Qui fabriquerait / validerait les moulinettes ? - COTE PARTENAIRES Il va falloir désabonner les contacts qui ont été transmis dans le cadre de cette opé. => Même procédure que pour l'incident précédent... Merci pour votre retour rapide. |
| Commentaire de Carole Visser [ 28/oct./10 10:08 ] |
|
Bonjour Carole,
Comme vu avec toi hier, je souhaite apporter une petite précision concernant le nouveau fichier d'import. Les colonnes optin et partenaire sont remplies par la fabrique à jeux de façon binaire en fonction de si la personne à cocher une case ou non. Dans le fichier, on observe pour de nombreux individus "non" dans la colonne optin et "oui" dans la colonne partenaire. Pour ces individus, il faut considérer qu'ils sont optin PriceMinister même s'il est mentionné que non car le "oui" dans la colonne partenaire signifie qu'il souhaite recevoir les offres de PriceMinister et de ses partenaires. A ta dispo si tu as des questions, Carole |
| Commentaire de Carole Boucheny [ 29/oct./10 09:40 ] |
|
Salut,
Je vais relancer l'import de contact. Avant cela je veux valider une dernière fois avec toi les abonnements. En gros, on a 3 cas : Optin Price, Optin Partenaire, Pas d'Optin. Dans le cas Optin Price, on abonne aux newletters : - HighTech - Culturelle - Mode - Maison - Auto Si Optin Partenaire : - HighTech - Culturelle - Mode - Maison - Auto - Partenaire Si pas d'Optin : Aucun abonnement. Merci Carole |
| Commentaire de Carole Visser [ 29/oct./10 14:21 ] |
| C'est ça! |
| Commentaire de Carole Visser [ 02/nov./10 16:29 ] |
|
Carole,
Je sais qu'il y a encore des problèmes avec les groupes d'abonnement mais il faudrait vraiment régler ça rapidement. On ne peut pas se permettre d'envoyer des news aux personnes qui ont déclaré ne pas vouloir en recevoir. Il faudrait également faire au plus vite la dédup du fichier que la fabrique à jeux a déposé hier sur le ftp.J'ai vraiment besoin de ces infos pour suivre la campagne d'affiliation. Merci de revenir vers moi au plus vite à ce sujet et n'hésite pas à faire signe si tu as des questions. Carole |
| Commentaire de Carole Boucheny [ 02/nov./10 17:09 ] |
|
Salut,
Le problème n'est pas si simple que cela à régler et demande l'intervention de d'autres équipes. Je travaille au maximum dessus pour te donner les éléments au plus vite. Je te tiens au courant des avancements. Carole |
| Commentaire de Carole Visser [ 03/nov./10 16:25 ] |
|
Carole,
Où en es-tu au niveau de la modification des abonnements et de l'import des nouveaux contacts? Peux-tu m'expliquer ce qui pose problème et quelles sont les équipes concernées afin que je comprenne un peu mieux d'où vient le blocage? Il faut vraiment avancer au plus vite sur le sujet. Merci Carole |
| Commentaire de Carole Boucheny [ 03/nov./10 16:46 ] |
|
Bonjour,
Pour résumer. Les contacts qui ont été créé vendredi 29 ont été abonnés aux newletters d'AVAL et de VMC. Demain, Patrick rentre de congé et pourra donc faire ces modifications dans notre base. Le BI pourra ensuite demander la mise à jour du côté d'AVAL et VMC. (Ce problème est apparue car la colonne qui correspond à ces abonnements dans nos tables temporaires est vide. Or le batch d'import de contact gère mal les nulls et abonne aux newletters. J'ai créé un jira pour ce problème APP-31579). En attendant une correction, plusieurs actions ont été faites et j'ai modifié mes scripts pour que ces colonnes ne soient jamais vide mais à 0. Les imports de contact normalement depuis ce matin. (Les batch tournent, on aura donc le comptage demain des nouveaux inscrits depuis le début). J'ai d'ailleurs été formée aujourd'hui, pour pouvoir lancer moi-même ces batchs (jusqu'à présent c'était l'exploit qui s'en occupait). La situation est donc presque rétablie, puisqu'il manque juste la modification en base. Et tu auras le comptage demain. Carole |
| Commentaire de Carole Boucheny [ 04/nov./10 16:25 ] |
|
Pour faciliter la récupération des nouveaux contacts, j'ai créer le script "rapport-market.pl" sur hercule.
Je le lancerais donc le lendemain de chaque import de contact. Et déposerais le fichier généré sur le ftp pour l'affiliation. Carole |
| Commentaire de Carole Boucheny [ 05/nov./10 14:56 ] |
| Pour info, les contacts qui avaient été inscrits à VMC et AVAL ont été désabonné dans notre base. Le BI envoi régulièrement les nouveaux et anciens inscrits aux newletters à AVAL et VMC. La mise à jour sera donc faite à ce moment là. (Il me semble que c'est le 10 de chaque mois). |
| Commentaire de Carole Boucheny [ 18/nov./10 12:05 ] |
| Le code tracking lorsque la personne n'a pas de code de provenance est 2317440. |
| Commentaire de Carole Boucheny [ 08/déc./10 10:05 ] |
| Le dernier import a eu lieu hier. |
[APP-17500] [Oracle] #100 ORA-00001: unique constraint (PRODUCT_1.CHK_PRODUCT_ID_RANK) violated Création: 08/août/07 09:03 Mise à jour: 02/oct./07 16:25 Résolue: 19/sept./07 15:38 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 15.0.0 |
| Version(s) corrigée(s): | 17.0.0 |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Ange Ferrari | Attribution: | Manuel Sadok |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Projets PM archivés: | Maintenance 17.x.x | ||||||||
| Description |
|
Voila la stack trace 2007-08-07 21:11:43,279 INFO [Processor292] jacques47 - >>> POST http://www.priceminister.com/referential!action=tracklisti...&issubmi t=true&popup=true&productid=56789975&submitbtn=Valider&title1-1=Mister Boo...&title1-2=Mopin'n Bi...&trackcount1=12 2007-08-07 21:11:43,279 INFO [Processor292] jacques47 - Same request - count=1 - delay=284ms 2007-08-07 21:11:43,447 WARN [Processor292] jacques47 - SQL Error: 1, SQLState: 23000 2007-08-07 21:11:43,447 ERROR [Processor292] jacques47 - [Oracle] #100 ORA-00001: unique constraint (PRODUCT_1.CHK_PRODUCT_ID_RANK) vio lated 2007-08-07 21:11:43,447 ERROR [Processor292] jacques47 - Could not synchronize database state with session org.hibernate.exception.ConstraintViolationException: could not insert: [com.babelstore.stock.entity.PrdSpecification] at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:69) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2077) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2426) at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:51) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:243) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:227) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:140) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:296) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:877) at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:201) at org.jboss.ejb3.entity.InjectedEntityManager.flush(InjectedEntityManager.java:122) at com.babelstore.stock.service.ProductManagerBean.flush(ProductManagerBean.java:1066) at sun.reflect.GeneratedMethodAccessor949.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:109) at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:32) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:113) at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:138) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:61) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:39) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:63) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:32) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:91) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:163) at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:60) at $Proxy271.flush(Unknown Source) at com.babelstore.stock.service.SpecificationServiceBean.addTracklistingSpecifications(SpecificationServiceBean.java:135) at sun.reflect.GeneratedMethodAccessor1147.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:109) at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:32) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:113) at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:138) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:61) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:39) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:63) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:32) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:91) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:163) at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:60) at $Proxy273.addTracklistingSpecifications(Unknown Source) at com.babelstore.referential.front.TracklistingViewAction.execute(TracklistingViewAction.java:263) at com.babelstore.util.web.Dispatcher.process(Dispatcher.java:343) at com.babelstore.util.web.Dispatcher.process(Dispatcher.java:299) at com.babelstore.util.web.Dispatcher.innerLoad(Dispatcher.java:212) at com.babelstore.util.web.Dispatcher.load(Dispatcher.java:185) at com.babelstore.util.web.Dispatcher.service(Dispatcher.java:153) at com.babelstore.util.web.Dispatcher.service(Dispatcher.java:115) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:138) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) |
| Commentaires |
| Commentaire de Manuel Sadok [ 19/sept./07 15:38 ] |
|
La réponse est dans les logs : "2007-08-07 21:11:43,279 INFO [Processor292] jacques47 - Same request - count=1 - delay=284ms " La personne a validé le mm formulaire de soumission de tracklisting 2 fois dans la foulée. |
[APP-7999] Fichiers non existants demandés sur le serveur Web (ErrorLog) Création: 16/mars/06 17:40 Mise à jour: 25/juin/07 18:36 Résolue: 20/mars/06 10:59 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 8.1.2 |
| Version(s) corrigée(s): | 8.1.2a |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Antoine Koener | Attribution: | Andrei Matyas |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Site: | Prod |
| Description |
|
Analyse de error_log après la 812: Error Apache: Erreurs liées à la 812: (première colonne f ou c, f pour file not found et c pour client denied by configuration) ~/bin/apache_error < error_log | sort -n -k 2 | grep V812 f 1 /usr/local/apache/htdocs/pmweb/virtualhost-francemobiles/content/V812/front/brand/francemobiles/images/header/tab_over_home.gif f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/brand f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/epik/auto f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/epik/images/auto/arrond-g.gif f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/epik/images/auto/header/logo.gif f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/epik/images/auto/header/tab_off f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/epik/images/auto/logo.gif f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/koobuycity/images/buY f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/virginmega/images/assistance/arrow/arrow_vehicle.gif f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/assistance/arrow/arrow_clothing.gif f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/box_checked_gray.gif f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/button/buy_clothing.gif f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/button/close.gif f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/barcode/barc f 2 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/epik/images/auto/cd-occasion.gif f 2 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/francemobiles/images/auto/footer f 2 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/assistance/arrow/arrow_electronics.gif f 2 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/assistance/arrow/arrow_music.gif f 2 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/assistance/arrow/arrow_white.gif f 3 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/camif/images/header/ f 3 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/assistance/arrow/arrow_books.gif f 3 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/assistance/arrow/arrow_games.gif f 3 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/bullet/bullet_sport.gif f 4 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/epik/images/auto/img f 4 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/assistance/arrow/arrow_computer.gif f 5 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/assistance/arrow/arrow_baby.gif f 5 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/bullet/bullet_music.gif f 6 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/ f 6 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/button/alert.gif f 7 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/bullet/bullet_video.gif f 8 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/assistance/arrow/arrow_video.gif f 8 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/bullet/bullet_baby.gif f 8 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/bullet/bullet_books.gif f 9 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/bullet/bullet_clothing.gif f 10 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/bullet/bullet_electronics.gif f 11 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/liberation/front f 12 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/bullet/bullet_games.gif f 17 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/assistance/arrow/arrow_hifi.gif f 19 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/bullet/bullet_white.gif f 21 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/bullet/bullet_hifi.gif referer: http://www.priceminister.com/boutique/DORNETTE/category/160756 referer: http://www.priceminister.com/boutique/adnauto69 f 26 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/bullet/bullet_computer.gif referer: http://bo.priceminister.com/boutique/TUNINGMANIA referer: http://www.priceminister.com/boutique/wild78/type/1780 referer: http://www.priceminister.com/boutique/delux/type/1780 f 37 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/francemobiles/images/header/tab_over_home.gif referer: http://francemobiles.priceminister.com/telephone-pda referer: http://francemobiles.priceminister.com/navigation?action=se&ss=15&kw=3500+cliparts&category=search_computer referer: http://francemobiles.priceminister.com/offer/buy/4723195/Samsung-SGH-E310-Telephone-cellulaire-avec-appareil-photo-numerique-GSM-Mobile.html f 46 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/assistance/arrow/arrow_vehicle.gif referer: http://bo.priceminister.com/boutique/TUNINGMANIA/type/1149 referer: http://www.priceminister.com/cart referer: http://www.priceminister.com/offer?action=profile&sellerlogin=Acc-auto f 46 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/wish/wish_promotion.gif f 91 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/default/cover_carminister.gif referer: http://www.priceminister.com/offer/vehicle/productid/18247845 f 105 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/images referer: http://www.priceminister.com/assistance/1200 f 334 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/camif/front f 2503 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/front referer: http://www.priceminister.com/assistance Les 30 erreurs les plus courantes ~/bin/apache_error < error_log | sort -n -k 2 | tail -30 f 98 /usr/local/apache/htdocs/pmweb/virtualhost-bo-jmh/visuels f 101 /usr/local/apache/htdocs/pmweb/virtualhost-www/visuels/2006-02-10-auto/108x724-auto.jpg f 110 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/images c 166 bargain c 166 home c 166 root_baby c 166 root_books c 166 root_clothing c 166 root_electronics c 166 root_games c 166 root_music c 166 root_sport c 166 root_vehicle c 166 root_video c 166 root_white c 166 root_wine c 166 tab_600 <------------- Qu'est ce que c'est comme URL ? c 166 tab_700 <--------------Même question c 166 travel f 190 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V7_2_4_a/front/brand/www/images/campaign f 196 /usr/local/apache/htdocs/pmweb/virtualhost-img/visuels/2006-02-27-autopromo/160x90-discount.gif f 241 /usr/local/apache/htdocs/pmweb/virtualhost-www/affiliation/visuels/coupon/paves_400x150 f 334 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/camif/front f 402 /usr/local/apache/htdocs/pmweb/virtualhost-www/MSOffice f 408 /usr/local/apache/htdocs/pmweb/virtualhost-www/_vti_bin c 608 /usr/local/apache/htdocs/pmweb/virtualhost-bi/maintenance.asis f 610 /usr/local/apache/htdocs/pmweb/virtualhost-bambinoccasion/maintenance.asis f 2503 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/front c 2657 403.html f 6634 /usr/local/apache/htdocs/pmweb/virtualhost-www/newsletter/2006-03-13-hitech57/spacer.gif referer: http://webmail16f.wanadoo.fr/webmail/fr_FR/read.html?IDMSG=2086&FOLDER=SF_INBOX&ORIGIN=SYSTEM_FOLDER Cette image est appelée par les tous les lecteurs de courrier en ligne ... /usr/local/apache/htdocs/pmweb/virtualhost-www/newsletter/2006-03-13-hitech57/spacer.gif, |
| Commentaires |
| Commentaire de Swan Desportes [ 16/mars/06 18:25 ] |
|
C'est quoi ce scandale ! f 6634 /usr/local/apache/htdocs/pmweb/virtualhost-www/newsletter/2006-03-13-hitech57/spacer.gif referer: http://webmail16f.wanadoo.fr/webmail/fr_FR/read.html?IDMSG=2086&FOLDER=SF_INBOX&ORIGIN=SYSTEM_FOLDER Cette image est appelée par les tous les lecteurs de courrier en ligne ... Wanadoo s'amuse à utiliser nos images ? |
| Commentaire de Quentin de Chivré [ 16/mars/06 19:19 ] |
|
Euh calmos... ;-) C'est peut-etre juste une de nos newsletter tu vois... |
| Commentaire de Andrei Matyas [ 20/mars/06 10:59 ] |
| J'ai ajouté tt les images www |
[EXP-2930] [INTEG FR et ES] Les deux sites d'Integ sont HS Création: 06/nov./06 10:32 Mise à jour: 25/juin/07 18:59 Résolue: 06/nov./06 17:33 |
|
| Etat: | Fermé |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Bloquant |
| Rapporteur: | Younès Charrière | Attribution: | Younès Charrière |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Description |
|
Le site d'Integ Espagne me renvoie pratiquement que des
pages indisponibles (pour la france c'est à peu près pareil). Il y a des erreurs dans les logs de MIGNON : 2006-11-06 10:10:43,136 INFO [P-Processor9] 192.168.1.220 - >>> GET http://www.es.integ/navigation/default/category/dvd-zona-1 2006-11-06 10:10:43,137 INFO [P-Processor9] 192.168.1.220 - Cache top_map - Init starting 2006-11-06 10:10:43,145 ERROR [P-Processor9] 192.168.1.220 - no.fast.ds.search.SearchEngineException: Failed to connect to http://192.168.1.16:15100/cgi-bi n/ with full url http://192.168.1.16:15100/cgi-bin/search?resultview=search&encoding=utf-8&query=and%28filter%28and%28meta.collection%3Astring%28%22ESINTEG%2 2%2C+mode%3D%22OR%22%29%2C+prdtypecode%3Astring%28%222248+2247+2243+2261+2241+2242%22%2C+mode%3D%22OR%22%29%2C+ratioprice%3Arange%28min%2C+float%280.8001%29% 2C+to%3D%22LT%22%29%2C+salescount30%3Arange%28int%283%29%2C+max%2C+from%3D%22GE%22%29%2C+not%28firstprdimageid%3Astring%28%220%22%2C+mode%3D%22OR%22%29%29%2C +stockquantity%3Arange%28int%283%29%2C+max%2C+from%3D%22GE%22%29%2C+prdvisibilitycode%3Aint%2810%29%29%29%29&qtpipeline=priceminister&rpf_navigation:enabled= true&hits=10&qtf_lemmatize=true&offset=0&language=es&sortby=-prdisavailable+-salescount30+default&version=v2.0.70 at no.fast.ds.search.http.HttpSearchEngine.searchInternal(HttpSearchEngine.java:196) at no.fast.ds.search.http.HttpSearchEngine.search(HttpSearchEngine.java:111) at com.babelstore.search.FastSearch.search(FastSearch.java:123) at com.babelstore.search.FastSearch.search(FastSearch.java:104) at com.babelstore.product.business.ProductCatalogBean.populateCategoryTop(ProductCatalogBean.java:773) at com.babelstore.product.business.ProductCatalogBean.populateCategoryTop(ProductCatalogBean.java:822) at com.babelstore.product.business.ProductCatalogBean.populateCategoryTop(ProductCatalogBean.java:822) at com.babelstore.product.business.ProductCatalogBean.getCategoryTopMap(ProductCatalogBean.java:741) at com.babelstore.product.business.ProductCatalogBean.load(ProductCatalogBean.java:598) at sun.reflect.GeneratedMethodAccessor186.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.invocation.Invocation.performCall(Invocation.java:345) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:214) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:185) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:130) at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:105) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:363) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:166) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:139) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624) at org.jboss.ejb.Container.invoke(Container.java:873) at sun.reflect.GeneratedMethodAccessor162.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80) at org.jboss.mx.server.Invocation.invoke(Invocation.java:72) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644) at org.jboss.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:155) at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:104) at org.jboss.invocation.InvokerInterceptor.invokeLocal(InvokerInterceptor.java:179) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:165) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55) at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:97) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:86) at $Proxy475.load(Unknown Source) at com.babelstore.common.business.CacheServiceBean$Cache.loadData(CacheServiceBean.java:268) at com.babelstore.common.business.CacheServiceBean$Cache.initData(CacheServiceBean.java:225) at com.babelstore.common.business.CacheServiceBean$Cache.getData(CacheServiceBean.java:187) at com.babelstore.common.business.CacheServiceBean$Cache.access$200(CacheServiceBean.java:151) at com.babelstore.common.business.CacheServiceBean.getData(CacheServiceBean.java:82) at sun.reflect.GeneratedMethodAccessor166.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.invocation.Invocation.performCall(Invocation.java:345) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:214) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:185) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:130) at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:105) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:363) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:166) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:139) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624) at org.jboss.ejb.Container.invoke(Container.java:873) at sun.reflect.GeneratedMethodAccessor162.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80) at org.jboss.mx.server.Invocation.invoke(Invocation.java:72) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644) at org.jboss.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:155) at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:104) at org.jboss.invocation.InvokerInterceptor.invokeLocal(InvokerInterceptor.java:179) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:165) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55) at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:97) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:86) at $Proxy445.getData(Unknown Source) at com.babelstore.common.business.CacheClient.getData(CacheClient.java:178) at com.babelstore.product.front.NavigationModel.isTopCacheInitialized(NavigationModel.java:490) at com.babelstore.product.front.DefaultNavigationAction.findRedirection(DefaultNavigationAction.java:102) at com.babelstore.product.front.DefaultNavigationAction.execute(DefaultNavigationAction.java:68) at com.babelstore.util.web.Dispatcher.process(Dispatcher.java:338) at com.babelstore.util.web.Dispatcher.process(Dispatcher.java:297) at com.babelstore.util.web.Dispatcher.innerLoad(Dispatcher.java:214) at com.babelstore.util.web.Dispatcher.load(Dispatcher.java:186) at com.babelstore.util.web.Dispatcher.service(Dispatcher.java:152) at com.babelstore.util.web.Dispatcher.service(Dispatcher.java:114) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:138) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) Caused by: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.Socket.connect(Socket.java:516) at java.net.Socket.connect(Socket.java:466) at sun.net.NetworkClient.doConnect(NetworkClient.java:157) at sun.net.www.http.HttpClient.openServer(HttpClient.java:365) at sun.net.www.http.HttpClient.openServer(HttpClient.java:477) at sun.net.www.http.HttpClient.<init>(HttpClient.java:214) at sun.net.www.http.HttpClient.New(HttpClient.java:287) at sun.net.www.http.HttpClient.New(HttpClient.java:299) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:796) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:748) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:673) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:917) at no.fast.ds.search.http.HttpSearchEngine.searchInternal(HttpSearchEngine.java:188) ... 112 more 2006-11-06 10:10:43,146 ERROR [P-Processor9] 192.168.1.220 - TransactionRolledbackException in method: public abstract java.lang.Object com.babelstore.comm on.business.Cacheable.load(java.lang.String,java.lang.Object,java.sql.Timestamp) throws java.rmi.RemoteException, causedBy: com.babelstore.search.SearchException: Fast Search not available. at com.babelstore.search.FastSearch.search(FastSearch.java:128) at com.babelstore.search.FastSearch.search(FastSearch.java:104) at com.babelstore.product.business.ProductCatalogBean.populateCategoryTop(ProductCatalogBean.java:773) at com.babelstore.product.business.ProductCatalogBean.populateCategoryTop(ProductCatalogBean.java:822) at com.babelstore.product.business.ProductCatalogBean.populateCategoryTop(ProductCatalogBean.java:822) at com.babelstore.product.business.ProductCatalogBean.getCategoryTopMap(ProductCatalogBean.java:741) at com.babelstore.product.business.ProductCatalogBean.load(ProductCatalogBean.java:598) at sun.reflect.GeneratedMethodAccessor186.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.invocation.Invocation.performCall(Invocation.java:345) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:214) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:185) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:130) at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:105) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:363) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:166) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:139) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624) at org.jboss.ejb.Container.invoke(Container.java:873) at sun.reflect.GeneratedMethodAccessor162.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80) at org.jboss.mx.server.Invocation.invoke(Invocation.java:72) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644) at org.jboss.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:155) at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:104) at org.jboss.invocation.InvokerInterceptor.invokeLocal(InvokerInterceptor.java:179) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:165) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55) at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:97) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:86) at $Proxy475.load(Unknown Source) at com.babelstore.common.business.CacheServiceBean$Cache.loadData(CacheServiceBean.java:268) at com.babelstore.common.business.CacheServiceBean$Cache.initData(CacheServiceBean.java:225) at com.babelstore.common.business.CacheServiceBean$Cache.getData(CacheServiceBean.java:187) at com.babelstore.common.business.CacheServiceBean$Cache.access$200(CacheServiceBean.java:151) at com.babelstore.common.business.CacheServiceBean.getData(CacheServiceBean.java:82) at sun.reflect.GeneratedMethodAccessor166.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.invocation.Invocation.performCall(Invocation.java:345) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:214) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:185) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:130) at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:105) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:363) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:166) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:139) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624) at org.jboss.ejb.Container.invoke(Container.java:873) at sun.reflect.GeneratedMethodAccessor162.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80) at org.jboss.mx.server.Invocation.invoke(Invocation.java:72) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644) at org.jboss.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:155) at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:104) at org.jboss.invocation.InvokerInterceptor.invokeLocal(InvokerInterceptor.java:179) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:165) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55) at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:97) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:86) at $Proxy445.getData(Unknown Source) at com.babelstore.common.business.CacheClient.getData(CacheClient.java:178) at com.babelstore.product.front.NavigationModel.isTopCacheInitialized(NavigationModel.java:490) at com.babelstore.product.front.DefaultNavigationAction.findRedirection(DefaultNavigationAction.java:102) at com.babelstore.product.front.DefaultNavigationAction.execute(DefaultNavigationAction.java:68) at com.babelstore.util.web.Dispatcher.process(Dispatcher.java:338) at com.babelstore.util.web.Dispatcher.process(Dispatcher.java:297) at com.babelstore.util.web.Dispatcher.innerLoad(Dispatcher.java:214) at com.babelstore.util.web.Dispatcher.load(Dispatcher.java:186) at com.babelstore.util.web.Dispatcher.service(Dispatcher.java:152) at com.babelstore.util.web.Dispatcher.service(Dispatcher.java:114) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:138) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) 2006-11-06 10:10:43,147 INFO [P-Processor9] 192.168.1.220 - Cache top_map - Init done in 10 ms 2006-11-06 10:10:43,149 INFO [P-Processor9] 192.168.1.220 - Cache top_map - Init starting 2006-11-06 10:10:43,156 ERROR [P-Processor9] 192.168.1.220 - no.fast.ds.search.SearchEngineException: Failed to connect to http://192.168.1.16:15100/cgi-bin/ with full url http://192.168.1.16:15100/cgi-bin/search?resultview=search&encoding=utf-8&query=and%28filter%28and%28meta.collection%3Astring%28%22ESINTEG%22%2C+mode%3D%22OR%22%29%2C+prdtypecode%3Astring%28%222248+2247+2243+2261+2241+2242%22%2C+mode%3D%22OR%22%29%2C+ratioprice%3Arange%28min%2C+float%280.8001%29%2C+to%3D%22LT%22%29%2C+salescount30%3Arange%28int%283%29%2C+max%2C+from%3D%22GE%22%29%2C+not%28firstprdimageid%3Astring%28%220%22%2C+mode%3D%22OR%22%29%29%2C+stockquantity%3Arange%28int%283%29%2C+max%2C+from%3D%22GE%22%29%2C+prdvisibilitycode%3Aint%2810%29%29%29%29&qtpipeline=priceminister&rpf_navigation:enabled=true&hits=10&qtf_lemmatize=true&offset=0&language=es&sortby=-prdisavailable+-salescount30+default&version=v2.0.70 2006-11-06 10:10:43,157 ERROR [P-Processor9] 192.168.1.220 - TransactionRolledbackException in method: public abstract java.lang.Object com.babelstore.common.business.Cacheable.load(java.lang.String,java.lang.Object,java.sql.Timestamp) throws java.rmi.RemoteException, causedBy: 2006-11-06 10:10:43,159 INFO [P-Processor9] 192.168.1.220 - Cache top_map - Init done in 10 ms 2006-11-06 10:10:43,159 INFO [P-Processor9] 192.168.1.220 - Cache top_map - Init starting 2006-11-06 10:10:43,165 ERROR [P-Processor9] 192.168.1.220 - no.fast.ds.search.SearchEngineException: Failed to connect to http://192.168.1.16:15100/cgi-bin/ with full url http://192.168.1.16:15100/cgi-bin/search?resultview=search&encoding=utf-8&query=and%28filter%28and%28meta.collection%3Astring%28%22ESINTEG%22%2C+mode%3D%22OR%22%29%2C+prdtypecode%3Astring%28%222248+2247+2243+2261+2241+2242%22%2C+mode%3D%22OR%22%29%2C+ratioprice%3Arange%28min%2C+float%280.8001%29%2C+to%3D%22LT%22%29%2C+salescount30%3Arange%28int%283%29%2C+max%2C+from%3D%22GE%22%29%2C+not%28firstprdimageid%3Astring%28%220%22%2C+mode%3D%22OR%22%29%29%2C+stockquantity%3Arange%28int%283%29%2C+max%2C+from%3D%22GE%22%29%2C+prdvisibilitycode%3Aint%2810%29%29%29%29&qtpipeline=priceminister&rpf_navigation:enabled=true&hits=10&qtf_lemmatize=true&offset=0&language=es&sortby=-prdisavailable+-salescount30+default&version=v2.0.70 2006-11-06 10:10:43,166 ERROR [P-Processor9] 192.168.1.220 - TransactionRolledbackException in method: public abstract java.lang.Object com.babelstore.common.business.Cacheable.load(java.lang.String,java.lang.Object,java.sql.Timestamp) throws java.rmi.RemoteException, causedBy: 2006-11-06 10:10:43,168 INFO [P-Processor9] 192.168.1.220 - Cache top_map - Init done in 9 ms 2006-11-06 10:10:43,169 ERROR [P-Processor9] 192.168.1.220 - Load error 2006-11-06 10:10:43,170 INFO [P-Processor9] 192.168.1.220 - Setting response status code to 503 2006-11-06 10:10:43,212 INFO [P-Processor9] 192.168.1.220 - <<< [75 ms] GET http://www.es.integ/navigation/default/category/dvd-zona-1 |
| Commentaires |
| Commentaire de Antoine Koener [ 06/nov./06 16:10 ] |
|
Ca refonctionne ? TU peux fermer le Jira ? |
| Commentaire de Younès Charrière [ 06/nov./06 17:33 ] |
| OK parfait merci Antoine :) |
[DEC-402] demande similaire à celle de Dorian pour le CD et le DVD Création: 26/juil./06 14:22 Mise à jour: 14/sept./07 14:44 Résolue: 02/nov./06 12:12 |
|
| Etat: | Fermé |
| Projet: | Reporting |
| Composants: | Trading |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Jany Marimoutou | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
J'ai besoin de rapport sur les meilleurs vendeurs de neuf d'une part, et d'occasion de l'autre : Avec comme principales caractéristiques : - Le nombre de vente - Leurs stocks - La quantités moyennes par produits - Le prix moyen de vente - Le CA par mois moyen Ceci pour les catégorie suivantes : Musique : - CD - Vinyle - Instruments de musique - Divers musique Vidéo - DVD ZONE 2 (normale + à droit locatif + Précommandes) - DVD ZONE 1 - VHS En CD j'aimerai également avoir un classement par "genre musicale" |
| Commentaires |
| Commentaire de Agathe Remy [ 02/août/06 19:09 ] |
|
Bonjour, Tes rapports sur les meilleurs vendeurs ont été développés et seront mis à jour tous les lundis dans la journée. Tu les trouveras dans l'intranet dans les répertoires à partir de lundi prochain : http://intra.priceminister.com/stats/reports/public/Stock//Music http://intra.priceminister.com/stats/reports/public/Stock//Video Le prix moyen et le CA moyen par mois sont des infos trop complexes à fournir. Quant au classement par genre musical, c'est aussi trop compliqué et gourmand en ressources. Cordialement, Agathe |
| Commentaire de Jany Marimoutou [ 31/août/06 16:11 ] |
|
Bonjour, Serait-il possible d'avoir en plus des éléments déjà fournis, le Chiffre d'Affaire pour chacun des vendeurs qui figure dans la liste ? Merci |
| Commentaire de Agathe Remy [ 02/nov./06 12:12 ] |
|
D'après Pascal, le reporting demandé a été mis en place via 4D en septembre. D'autre part, afin d'éviter de faire le même travail dans 4D et BI, toutes les demandes de reporting doivent être validées au préalable par Pascal. Merci:-) Cordialement, Agathe |
[EXP-1631] batch holiday : il pourrait etre a l'origine de nos pb de perf. Il faudrait organiser une audit avec le dev... Création: 27/mars/06 09:38 Mise à jour: 08/août/07 19:22 Résolue: 08/août/07 19:22 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Justin Ziegler | Attribution: | Patrice Boulanger |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Commentaires |
| Commentaire de Justin Ziegler [ 27/mars/06 09:38 ] |
|
cf graphe / hercule (user in state transit) j'ai l'impression que la forme est anormale ou alors c'est peut etre des comptes avec de nombreuses annonces qui sont mis en vacances / qui reviennent ce qui demande bcp de travail au batch holidays. dans tous les cas, cela pourrait etre la cause de nos pb de charge sur la base. |
| Commentaire de Justin Ziegler [ 27/mars/06 09:49 ] |
| Il pourrait etre interessant de regarder l'evenement de mise en vacances automatique afin de voir si il y a plus de mise en vacance auto qu'avant (etude a voir avec l'equipe BI). |
| Commentaire de Antoine Koener [ 09/août/06 10:16 ] |
|
A correler avec les exceptions du 8 aout au soir. |
| Commentaire de Justin Ziegler [ 08/août/07 19:22 ] |
| On ferme ! |
[APP-10436] [Affiliation] Les stats Xiti pour l'affiliation bugent à partir de la mise en ligne du site Création: 12/juin/06 17:56 Mise à jour: 25/juin/07 18:40 Résolue: 05/juil./06 17:02 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 9.0.0.1 |
| Version(s) corrigée(s): | 9.0.1 |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Ghislain Gridel | Attribution: | Swan Desportes |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
screenshot-1.jpg
screenshot-1.jpg
screenshot-1.jpg
screenshot-1.jpg
screenshot-1.jpg
XITI.jpg
|
| Description |
|
Swan, tu remarqueras que les statistiques ne sont pas cohérentes entre la page 1 et la page 2 pour l'affiliation. L --> problème de tag ! Il semble ne plus être pris en compte à partir du 6 juin. cf copies-écran Merci |
| Commentaires |
| Commentaire de Swan Desportes [ 14/juin/06 09:57 ] |
|
Il y avait un problème de syntaxe sur l'EntryEventBlock
suite à l'ajout d'un alt="" pour la conformité XHTML : corrigé. D'autres problèmes possibles : l'utilisation d'un & au lieu d'un & dans les URL. Il est possible que cela soit mal interprété par certains navigateurs : retour à la précédente syntaxe. On espère un retour à l'ordre suite à la mise en prod de la nuit prochaine --> les stats de Jeudi (visible Vendredi) devraient être bonnes. |
| Commentaire de Christophe Garcia [ 15/juin/06 17:32 ] |
| A vérifier en live sur la PROD demain |
| Commentaire de Ghislain Gridel [ 19/juin/06 10:29 ] |
|
Bonjour Swan, après vérification les stats bugent toujours. cf copie écran. |
| Commentaire de Swan Desportes [ 19/juin/06 12:50 ] |
|
Effectivement, un second bug trainait : <script type="text/javadscript"> au lien de <script type="text/javascript"> Cette faute faisait que le tag Entrée n'était pas interprêté... |
| Commentaire de Ghislain Gridel [ 05/juil./06 11:10 ] |
|
Au 05/07/06, les résultats du tracking Xiti semblent toujours très faible. Jen conclue que le bug n'est pas réparé. Pouvez-vous revenir vers moi avec un diagnostic ? Merci ! Ghislain |
| Commentaire de Swan Desportes [ 05/juil./06 11:26 ] |
| En regardant XITI Tracking, tout semble etre en ordre sur le tag Entrée. Les stats "Entrée" sont de nouveau volumineuses. |
| Commentaire de Swan Desportes [ 05/juil./06 11:32 ] |
|
Cette baisse de volume est un problème d'un autre ordre. Est on en contradiction avec Effiliation ? Que donnent les rapport BI sur le tracking Effiliation ? |
| Commentaire de Swan Desportes [ 05/juil./06 17:02 ] |
| vu avec Ghislain, c'est ok |
| Commentaire de Lydia Dali [ 05/juil./06 18:01 ] |
|
http://v50.xiti.com/stats/frequentation/vvp_courbe.asp?d=05/06/2006&f=04/07/2006&ng=0-0&q2=7912&q8=1 ok |
[CAT-328] Rédaction d'une document de spécification - Chiffrage sur les BBD Produits Création: 22/sept./06 14:22 Mise à jour: 03/juil./08 16:19 Résolue: 03/juil./08 16:18 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Non Import |
| Composants: | Référentiel |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Marion Anfreville | Attribution: | Marion Anfreville |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | 15 minutes | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Alerte_livraison_SPEC.doc
requete_rapport_erreurs_hebdo.txt
SPEC_BDD_Controle_Qualite.doc
|
| Pays: |
FRA - France
|
| Description |
|
Rédiger un document de spécifications sur la mise en place de rapports sur les données présentes dans nos bases.
|
| Commentaires |
| Commentaire de Marion Anfreville [ 21/mai/07 16:41 ] |
|
Actuellement, la spécification contient les grandes lignes
pour la mise en place d'alertes et rapports pour un meilleur suivi des
BDD produits. La spécification ne pourra être finalisée sans avoir tous les éléments techniques de réalisation. Pour le moment, le côté rapports est en suspend à cause du chantier sbp. Le rapport pourrait être fourni par l'équipe BI mais ils attendent ce chantier pour intégrer les attributs à business object. |
| Commentaire de Marion Anfreville [ 25/mai/07 17:39 ] |
| en pj, le document de spécification des besoins alertes => Alerte_livraison_SPEC.doc |
| Commentaire de Marion Anfreville [ 03/juil./08 16:19 ] |
| V1 des alertes mis en place. A étoffer par la suite. |
[BIN-155] [Affiliation] : rapport affiliation acheteurs Création: 19/sept./06 13:23 Mise à jour: 14/sept./07 17:20 Résolue: 05/mars/07 17:18 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Ghislain Gridel | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Description |
|
Agathe, Cela fait plusieurs mois que nous parlons du rapport de validation des ventes pour l'affiliation. La demande avait été faite par François-Marie à l'époque. Quand ce rapport pourra-t-il être réalisé ? Ghislain |
| Commentaires |
| Commentaire de Agathe Remy [ 19/sept./06 14:01 ] |
|
Ghislain, Nous pourrons traiter cette demande en même temps que le rapport d'affiliation. J'ai plannifier ce projet d'ici fin 2006, après les projets 1000Mercis et BI Espagne, à savoir en décembre. Cordialement, Agathe |
| Commentaire de Agathe Remy [ 09/oct./06 12:46 ] |
|
Vu avec OSA : ce rapport passe en P2. Agathe |
| Commentaire de Romain Czornomaz [ 21/févr./07 17:59 ] |
|
Les modifications du rapport sont OK. Tu peux le valider sur le dev. Merci, Romain |
Affiliation Programme Vendeur :: Metatache
(APP-15282)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Affiliation |
| Affecte la/les version(s): | ToDo |
| Version(s) corrigée(s): | 17.0.0 |
| Type: | Sous-tâche | Priorité: | Mineur |
| Rapporteur: | Ghislain Gridel | Attribution: | Romain Czornomaz |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Projets PM: | *** RESERVE *** |
| Projets PM archivés: | Affiliation vendeur |
| Commentaires |
| Commentaire de Ghislain Gridel [ 23/févr./07 16:25 ] |
|
Romain, il s'agit de créer un rapport pour pouvoir valider les ventes (on parlera désormais de validation des achats pourle programme achat). Voilà les éléments dont nous aurions besoin : GROUPE DE TRACKING TRACKING LOGIN DATE ET HEURE DE MISE EN VENTE N° ANNONCE PREMIERE MISE EN VENTE OU NON ANNONCE VENDUE OU NON A ta dispo pour toute question Ghislain |
| Commentaire de Romain Czornomaz [ 27/juil./07 15:58 ] |
|
Ghislain, Les rapport BI pour suivre l'affiliation vendeur sont déployés. Bonne journée, Romain |
[DEC-459] Ecart Tableau de bord / articles Création: 28/sept./06 16:26 Mise à jour: 14/sept./07 15:19 Résolue: 19/janv./07 18:08 |
|
| Etat: | Fermé |
| Projet: | Reporting |
| Composants: | Trading |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Benjamin Guerville | Attribution: | Agathe Remy |
| Résolution: | Invalid | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour, je remarque des écart de chiffres entre le tableau de bord et l'item history. Exemple : ventes de mobiles le 01/09/2006 Tabeau de bord : 17 336 Somme items (sauf supprimés) : 16 797,63 Somme items + port (sauf supprimés) : 18053,80 Somme items (avec supprimés) : 21 523,04 Somme items + port (avec supprimés) : 23 116,84 A quoi correspond exactement la somme indiquée dans le tableau de bord. Merci |
| Commentaires |
| Commentaire de Agathe Remy [ 19/janv./07 18:08 ] |
|
Les données du tableau de bord BackOffice ne sont pas
produites par le pôle BI et ne sont pas maintenues par les pôle
Développement. Elles ne sont donc pas fiables. Cordialement, Agathe |
[BIN-160] NpF - nb de produits par famille Création: 29/sept./06 16:15 Mise à jour: 14/sept./07 17:20 Résolue: 25/oct./06 18:48 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Bloquant |
| Rapporteur: | Estelle Coulon | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | 1 jour | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | 1 jour | ||
| Pièces jointes: |
Nombres de produits par type.xls
|
| Pays: |
FRA - France
|
| Description |
|
Agathe, Comme évoqué hier je souhaiterai obtenir les données suivantes par famille: Nb de produits avec annonces Nb de produits sans annonces Nb de FP active Nb de FP non active En fait les données d'Emmanuel ne sont pas bonnes car je pense que ces requetes sous Business Objects sont ko. Merci de voir quand tu peux faire ca, idealement rapidement. Estelle |
| Commentaires |
| Commentaire de Agathe Remy [ 29/sept./06 16:58 ] |
|
Ta demande sera priorisée en P1/P2 BI vendredi prochain. Merci:-) Agathe |
| Commentaire de Estelle Coulon [ 24/oct./06 14:51 ] |
|
Quel est le resultat de la priorisation? Je suis tjs preneuse de cette info. merci Estelle |
| Commentaire de Agathe Remy [ 25/oct./06 18:48 ] |
|
Tu trouveras ci-joint les données demandées. J'espère qu'elles te conviendront. N'hésite pas à venir me voir si tu as des questions:-) Agathe |
[I18N] Refonte Country
(APP-11799)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Base de données |
| Affecte la/les version(s): | 9.0.3.1.c |
| Version(s) corrigée(s): | 14.0.0 |
| Type: | Sub-bug | Priorité: | Mineur |
| Rapporteur: | Renaud Dierickx | Attribution: | Edouard Gomez-Vaez |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
screenshot-1.jpg
|
||||||||
| Liens des demandes: |
|
||||||||
| Pays: |
ALL - Tous
|
||||||||
| Classif1: | I18N | ||||||||
| Classif2: | I18N - finition currency | ||||||||
| Projets PM archivés: | Maintenance 11.0.0 | ||||||||
| Description |
|
Salut Patrick, Peux-tu déplacer dans admin_1 les tables CURRENCY et STATE ? Il semblerait qu'EXCHANGE_RATE ne soit plus utilisé (elle est vide dans purchase) si c'est le cas, peux-tu la supprimée ? Merci d'avance. |
| Commentaires |
| Commentaire de Renaud Dierickx [ 02/nov./06 17:49 ] |
| J'ai supprimé la table 'exchange_rate' car elle n'était jamais utilisée... Il faudra voir si on souhaite la recréer pour la refonte currency (voir screenshot-1) |
| Commentaire de Renaud Dierickx [ 02/nov./06 18:35 ] |
|
Les scripts sont écris... On les passe pour quelle version ??? La V1000 ou celle d'après ??? Si on les passe, il faut que Patrick P pense à y ajouter un synonyme pour le BI dans le script 3. C'est critique !!! |
| Commentaire de Arnaud Forgues [ 03/nov./06 11:30 ] |
|
on va plutot attendre après la V10. Par contre il reste à faire les scripts pour la table STATE |
| Commentaire de Renaud Dierickx [ 03/nov./06 12:44 ] |
| C'est fait... J'ai mis mes scripts dans le répertoire waiting et j'attends de voir comment on va procéder pour la prochaine version... |
| Commentaire de Edouard Gomez-Vaez [ 02/mars/07 16:30 ] |
| test jira |
| Commentaire de Edouard Gomez-Vaez [ 02/mars/07 18:50 ] |
| test JIRA |
| Commentaire de Renaud Dierickx [ 15/mars/07 12:23 ] |
| Tu en es où dans ton test ??? Je te réassigne le jira. |
| Commentaire de Edouard Gomez-Vaez [ 15/mars/07 14:18 ] |
| Désolé, je la ferme ! |
[EXP-2858] archivage des data OLTP : prévoir un axe d'archivage pour usr_event Création: 18/oct./06 14:55 Mise à jour: 15/sept./08 10:55 Résolue: 15/sept./08 10:55 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Justin Ziegler | Attribution: | Samir Beghdadi |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Commentaires |
| Commentaire de Patrick Pereira [ 14/avr./08 18:00 ] |
| Bloqué en attente du développement par l'équipe BI d'un client permettant de consulter les usr_event sur la base d'archive. |
| Commentaire de Ayoub Benseghir [ 14/août/08 11:23 ] |
| L'archivage et l'épuration de USR_EVENT sont en place, on a libéré la prod de 200M de lignes (+- 12Go de données). |
[EXP-3199] mise à jour plages de ecb Création: 29/janv./07 14:01 Mise à jour: 08/janv./10 15:07 |
|
| Etat: | Ré-ouvert |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Steven Harel | Attribution: | Arnaud Forgues |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Pays: |
ALL - Tous
|
||||||||
| Description |
|
on a un gros souci avec les ecartes depuis pas-mal de temps y'a plein de coupons utilisés frauduleusement : une partie du budget marketing/coupon part chez les fraudeurs (et pas pour le recrutement des nouveaux acheteurs) qui créent autant de compte et font autant d'achat qu'ils ont de ecartes au bo, on passe notre temps à essayer de les chopper et on n'y arrive pas souvent le dernier qu'on a attrapé nous devait 15.000 euros !! pourquoi ? parce que la base des ecartes intégrée dans le système n'est pas à jour c'est ce qui nous permet d'identifier et de refuser les commandes ecarte/coupon benoit a réussi à avoir les plages mises à jour est-ce que tu penses qu'on peut facilement/rapidement ajouter les nouvelles plages à celles que l'on a déjà paramétrées ? |
| Commentaires |
| Commentaire de Patrice Boulanger [ 29/janv./07 18:45 ] |
|
Steven, Peux-tu nous mettre le contenu de la base dans ce jira? Ensuite, on pourra le passer sur les serveurs applicatifs. Il faut préciser si c'est une base complète ou une mise à jour. Merci. Patrice. |
| Commentaire de Steven Harel [ 30/janv./07 10:05 ] |
|
c'est a priori une mise à jour, il y aurait des plages
supplémentaires, d'autres auraient été modifiées. il faut intégrer les 6
premiers chiffres des numéros de cb suivants la ecb est une grosse faille dans notre système si les infos ne sont pas correctement paramétrées. on a vu que certains utilisateurs nous faisaient perdre des dizaines de milliers d'euros. il est vraiment indispensable que tu t'assures que ces pages sont paramétrées parfaitement vu qu'il n'est pas vraiment possible de faire des tests derrière. société générale : 415056 caisse d'épargne 420110 420111 420112 420113 420114 420115 420116 lcl : 415055 banque postale (visa) : 415059 banque postale (ecmc) : 513001 banque pop : 415058 415060 415061 415062 415063 415064 415065 415066 415067 415068 415069 415070 415071 415072 415073 415074 405935 405936 405937 405938 405939 405940 405941 405942 405943 405944 |
| Commentaire de Steven Harel [ 15/févr./07 14:29 ] |
|
peux-tu me donner le détail des différences entre la base actuelle et la nouvelle ? merci |
| Commentaire de Patrice Boulanger [ 15/févr./07 15:38 ] |
| Je retrouve tous les numéros ci-dessus dans la base actuellement en prod. |
| Commentaire de Patrice Boulanger [ 15/févr./07 15:40 ] |
|
Plus précisément, il y a aussi les numéros suivants en prod: 41506 415935 415936 415937 415938 415939 415940 415941 415942 415943 415944 496612 497612 497784 513220 513226 513284 513612 529477 |
| Commentaire de Steven Harel [ 28/févr./07 13:49 ] |
|
nous allons créer nos propres plages de ecb. notamment en identifiant les fraudes ecb/coupon et en demandant systématiquement les 5ème et 6ème chiffre de la ecb nous aurons de nouvelles infos régulièrement peut-on laisser ce jira ouvert et communiquer les nouveaux chiffres par ce biais ? la première plage qui pose de gros problèmes est : 5132 68 peux-tu l'intégrer dans le système le plus rapidement possible ? merci |
| Commentaire de Patrice Boulanger [ 09/mars/07 12:28 ] |
|
Jérémie, Merci d'ajouter le numéro ci-dessous dans la propriété priceminister.purchase.ecartebleue sur tous les JBOSS. On garde donc le JIRA ouvert pour suivre les mises à jour. |
| Commentaire de Jérémie Bennejean [ 09/mars/07 12:55 ] |
|
La maj est faite sur tous les jboss. Je baisse la priorité et je laisse le jira ouvert pour de nouveaux ajouts si besoin est. |
| Commentaire de Eve Pioche [ 29/juil./09 15:47 ] |
|
MAJ 4 nouvelles plages e-CB détectées à ajouter en prod : Caisse d'épargne : - 420117 - 420118 Crédit Mutuel : - 497768 Banque non indentifiée (Portugal ?) - 465963 Merci |
| Commentaire de Eve Pioche [ 29/juil./09 15:53 ] |
|
Une autre plage qui n'est semble t-il pas encore en prod non plus : - 513201 |
| Commentaire de Jérémie Bennejean [ 07/janv./10 17:46 ] |
|
Nicolas, Je te transfère ce jira car la property se trouve dans le priceminister.properties. Je ne préfère pas l'overloader, sinon ca va devenir ingérable. |
| Commentaire de Nicolas Chauveau [ 07/janv./10 18:00 ] |
| A passer en TX-L |
| Commentaire de Arnaud Forgues [ 08/janv./10 15:07 ] |
|
Donc la propriété à mettre à jour est bien la suivante ? priceminister.purchase.ecartebleue = Jérémie, quelle(s) est(sont) la(les) bonne(s) valeur(s) à mettre par rapport à la PROD (FR / ES / UK) ? D'autre part, je ne vois pas d'inconvénient à mettre à jour les dernières valeurs de cette propriété directement dans le priceminister.properties, mais, à mon avis, il s'agit d'un cas de propriété qui correspond bien à l'utilisation de l'overload : cela est indépendant de l'application / dev et évolue donc en permanence ... |
Installation de la solution de sauvegarde
(EXP-2751)
|
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Installation |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Sous-tâche | Priorité: | Mineur |
| Rapporteur: | Patrice Boulanger | Attribution: | Stéphane Eccli |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Commentaires |
| Commentaire de Patrice Boulanger [ 29/sept./06 11:19 ] |
| Ce jira rassemble les éléments nécessaire pour la mise en place de la stratégie de sauvegarde (qu'est-ce-qu'on backup ? quand ?) |
| Commentaire de Patrice Boulanger [ 29/sept./06 11:21 ] |
|
Comptabilité: backup les données CEGID. Quand? tous les jours ouvrés (lundi-vendredi) à 21h Quoi? le dump de la base MSSQL qui est effectuée automatiquement à 20h Retention: à définir avec Philippe Favrot |
| Commentaire de Patrice Boulanger [ 29/sept./06 11:22 ] |
|
BI: Agathe m'a parlé d'un JIRA qui a été fait avec Jérémie il y a deux mois... Jérémie peux-tu retrouver ces infos? |
| Commentaire de Patrice Boulanger [ 29/sept./06 11:23 ] |
|
Données utilisateurs: Quand? tous les jours durant la nuit (minuit?) Quoi? le contenu de tous les répertoires utilisateurs Retention: à définir |
| Commentaire de Patrice Boulanger [ 29/sept./06 11:24 ] |
|
Base de données: backuper les bases de données des outils: JIRA, Sysaid, ... Quand? Tous les jours durant la nuit (minuit?) Quoi? à voir avec Patrick? stopper la base la nuit et backuper les fichiers? Retention: à définir |
| Commentaire de Patrice Boulanger [ 29/sept./06 11:26 ] |
|
Réaliser un document (sur le wiki exploit) pour expliquer la stratégie de sauvegarde. Ce document sera publié pour information aux utilisateurs après la mise en place définitive de la politique de sauvegarde. |
| Commentaire de Patrice Boulanger [ 29/sept./06 11:27 ] |
|
Arnaud, Peux-tu voir avec Philippe pour la rétention nécessaire des données? Si ce délai est très long, il faudra prévoir de réserver des tapes spécifiques pour ce contenu. A voir avec le consultant qui installera la solution de sauvegarde. |
| Commentaire de Patrice Boulanger [ 29/sept./06 12:23 ] |
|
Voir aussi avec Philippe s'il y a d'autres données
financières/RH à sauvegarder. Peut-être lui créer un lecteur réseau
spécifique qui sera aussi sauvegarder sur la tape spécifique à la
compta. Merci. |
| Commentaire de ZZ_Arnaud Baali [ 29/sept./06 17:14 ] |
|
J'ai vu avec philippe pour la rétention d'informations: il
n'y a aucune limite de conservation dans le temps. Il faudra donc
disposer de cassettes à remplir indéfiniement pour les données de
comptas d'une année sur l'autre |
| Commentaire de Patrice Boulanger [ 29/sept./06 17:38 ] |
| En même temps, il faudra décrire ce cas à l'intégrateur pour en discuter avec lui. Il y a peut être une meilleure solution. Si on laisse ce genre d'info sur une seule bande et qu'elle est défectueuse, volée, perdue, brûlée, ... on perd tout !!! |
| Commentaire de Patrice Boulanger [ 27/oct./06 15:51 ] |
|
Arnaud, Afin de commencer cette tâche, pourrais-tu commencer par faire une estimation de la volumétrie totale des différents serveurs de la plateforme interne? Merci. |
| Commentaire de Quentin de Chivré [ 06/juil./07 16:01 ] |
| Arnaud Baali -> Patrice |
| Commentaire de Patrice Boulanger [ 20/août/07 14:08 ] |
|
Jérôme, Merci de nous mettre ici la liste des serveurs backupés avec une estimation de la volumétrie (ça sera à reprendre dans le rapport service desk). On pourra ensuite clore cette sous tâche. Merci. |
| Commentaire de Ange Ferrari [ 16/sept./08 17:48 ] |
| Je sais pas si c'est toujours d'actualité mais comme tu es le roi de la sauvegarde Stéphane :) |
| Commentaire de Stéphane Eccli [ 17/sept./08 09:31 ] |
| ok |
[EXP-3135] Réalisation d'un Export pour Mixad. Création: 03/janv./07 15:30 Mise à jour: 25/juin/07 19:00 Résolue: 21/févr./07 14:57 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Flux |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Benoît Bourdon | Attribution: | Edouard Laurent |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
PM - Mixad-retour yves 2006-02-07.xls
|
||||||||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Description |
|
Les champs sont décrit dans le fichier excel joint. Dans un premier temps on génère un export pour aujourd'hui pour qu'ils testent. On attend les commentaire de MIXAD lundi, puis on génèrera des exports quotidiens. Cet Export concerne l'export des annonces Auto uniquement pour les PRO Les champs attendus sont en pièces jointes dans le fichier Excel. Je peux passer te voir pour le completer ( pour : nom du champ et de la table concernée en base) |
| Commentaires |
| Commentaire de Benoît Bourdon [ 08/janv./07 16:50 ] |
|
Voici les retouches suite aux retours du client : - Retirer les photos génériques (quand il n'y a pas de photo pour le produit complement) - Quand il y a une photo, selectionner la grande version ( "_L" à la place de "_S " à la fin du nom de la photo) - Supprimer les champs suivants : o Nombre de chevaux fiscaux o Cylindrée o Nombre de vitesse o Couleur intérieure Cet export devait être bi-hebdo. si ce n'est pas possible - quotidien semble plus simple - autant le faire quotidien. Le fichier généré est à déposer sur le FTP suivant : ftp.mixad.com login : priceminister password : pm#;1428 (on peut ré-écraser tous les jours le fichier de la veille, pas de soucis) Idéalement pour eux il faudrait envoyer un fichier non compressé. Merci Edouard. Tu pourra m'envoyer la requete que je l'ajoute dans la doc que j'ai fait pour cet export. |
| Commentaire de Edouard Laurent [ 09/janv./07 11:37 ] |
| C'est en place, le flux est envoyer quotidiennement sur leur ftp |
| Commentaire de Benoît Bourdon [ 26/janv./07 14:35 ] |
|
Flux mis en oeuvre : liste des évolutions possible (mais non souhaités pour l'instant) Ø Envoyer plusieurs photos lorsqu'il y en a. Ø Augmenter le nombre d'attributs que nous envoyons (il faut avant mesurer l'impact sur référencement par rapport au gain ?) Ø Format « TOP vendeur » (mais il faut que le concessionnaire et ses coordonnées complètes soir dans la base des concessionnaires Mixad + il faut envoyer plusieurs photos + une description plus complète) -> Idem point ci-dessus : à voir si impact réferencement / gain Ø Ajouter l'attribut « segment » dans le flux (l'intérêt se situe pour les voitures type cabriolet / coupé / sport que nous réunissons en une seule catégorie et que Mixad « dispatch » en plusieurs - ça suppose que ce champ soit aussi renseigné par les PROs pour les imports) Ø Eviter le doublonnage d'annonces issues de notre base (dû, chez nous entre autre, à des véhicules appartenant à plusieurs catégories). (avant mise en oeuvre - il faudra mesurer le risque que cela génère au referencement - duplicate content - par rapport au gains génèrés par le flux ...) |
| Commentaire de Benoît Bourdon [ 20/févr./07 10:34 ] |
|
Comme vu par mail : Il faut quue nous limitions le nombre d'annonces sur : La date de modification de l'advert en prennant les annonces de moins de 30 jours. Merci ! |
| Commentaire de Edouard Laurent [ 21/févr./07 14:57 ] |
| Voila c'est en place : modification en prod a partir de demain soit 22 fev 2007 |
[APP-13675] Valeurs NULL dans champs ALLOW_PICKUP et ALLOW SHIPPING Création: 08/nov./06 17:09 Mise à jour: 20/nov./07 16:52 Résolue: 05/oct./07 12:08 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 18.0.0 |
| Type: | Bogue | Priorité: | Cosmétique |
| Rapporteur: | François Le Lay | Attribution: | Mostafa Diane |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM: | *** RESERVE *** |
| Classif1: | DB |
| Description |
|
Nous avons remarqué que les champs ADVERT.ALLOW_PICKUP et ADVERT.ALLOW_SHIPPING ont des valeurs NULL, 0 et 1. Il s'agit d'annonces voitures essentiellement, créées entre Juin 2005 et Mars 2006. A priori suite à la mise place de cette fonctionnalité les anciennes annonces voitures n'ont pas eu ces champs updatés. A noter que certains autres types de produits sont concernés mais sur des cardinalités moindres. SELECT TRUNC(CREATION_DATE,'MM'), PRD_TYPE_CODE.LABEL, ADV_STATUS_CODE.LABEL, COUNT(*) FROM ADVERT, PRD_TYPE_CODE, ADV_STATUS_CODE WHERE ALLOW_PICKUP IS NULL AND ADVERT.PRD_TYPE_CODE = PRD_TYPE_CODE.PRD_TYPE_CODE AND ADVERT.ADV_STATUS_CODE = ADV_STATUS_CODE.ADV_STATUS_CODE GROUP BY TRUNC(CREATION_DATE,'MM'), PRD_TYPE_CODE.LABEL, ADV_STATUS_CODE.LABEL ; 01/06/2005 Voitures Active 1496 01/06/2005 Voitures Fermée 2955 01/07/2005 Voitures Active 1366 01/07/2005 Voitures Fermée 3057 01/08/2005 Voitures Active 1831 01/08/2005 Voitures Fermée 2658 01/09/2005 Voitures Active 1955 01/09/2005 Voitures Fermée 4564 01/10/2005 Voitures Active 1178 01/10/2005 Voitures Fermée 5778 01/10/2005 Voitures Brouillon 97 01/10/2005 Voitures En attente de publication 151 01/10/2005 Voitures_c Fermée 6 01/11/2005 Voitures Active 440 01/11/2005 Voitures Fermée 3217 01/11/2005 Voitures Brouillon 305 01/11/2005 Voitures En attente de publication 277 01/12/2005 Voitures Active 267 01/12/2005 Voitures Fermée 1908 01/12/2005 Voitures Brouillon 205 01/12/2005 Voitures En attente de publication 171 01/12/2005 Voitures_c Fermée 1 01/01/2006 Voitures Active 490 01/01/2006 Voitures Fermée 2581 01/01/2006 Voitures Brouillon 352 01/01/2006 Voitures En attente de publication 177 01/02/2006 Voitures Active 347 01/02/2006 Voitures Fermée 1190 01/02/2006 Voitures Brouillon 232 01/02/2006 Voitures En attente de publication 91 01/02/2006 Livres anciens Fermée 1 01/03/2006 Vêtements Active 5 01/03/2006 Vêtements Fermée 1 01/03/2006 Décoration Active 3 01/03/2006 Livres anciens Fermée 14 01/03/2006 Abonnements Presse Active 8 01/03/2006 Emetteur-récepteur Fermée 1 01/03/2006 Livres en pré-commande Fermée 3 01/03/2006 FB Equipements scolaires Fermée 1 |
| Commentaires |
| Commentaire de Mostafa Diane [ 05/oct./07 12:08 ] |
|
Effectivement les champs ALLOW_PICKUP et ALLOW SHIPPING
peuvent être null. Ca vient de la non mise à jour de la table advert. (a
noter que il y'a plusieurs champs sur advert qui sont null). J'ai vu avec Samir et il m'a confirmé que les deux champs sont nullable sur la base de BI, je peux confirmer que au niveau applicatif ca nous ne gène pas d'avoir ces champs nulls. je crois, sans être pourtant sur a 100 %, que on n'a pas jugé necessaire d'initialiser les champs car l'initialisation est trop couteuse. Si jamais vous avez une raison pour que les deux champs soint NOT NULL, ouvre moi au autre jira. |
| Commentaire de Nicolas Chauveau [ 12/oct./07 08:51 ] |
|
Tag oublié [CAJ200710] |
| Commentaire de Agathe Remy [ 12/oct./07 13:33 ] |
|
Bonjour, Le JIRA avait été ouvert à la demande de l'équipe dév afin qu'un jour soi traitée l'initialisation. En effet, il n'y a pas de blocage applicatif parce que sinon le JIRA aurait eu une priorité plus haute:-) C'est juste une histoire de cohérence des données (tous les autres flags du même type sont initialisés) afin de pouvoir les exploiter. Merci:-) Agathe |
[EXP-2957] Mise à jour perignon en Red Hat AS4 Création: 08/nov./06 12:59 Mise à jour: 25/juin/07 18:59 Résolue: 08/mars/07 16:03 |
|
| Etat: | Fermé |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | François Le Lay | Attribution: | Jérémie Bennejean |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Description |
|
Dans le cadre du projet de migration Business Objects XI
vers XI Release 2 j'ai besoin que perignon soit upgradée en AS4
(Actuellement en AS3 Update 6). Désolé ;) |
| Commentaires |
| Commentaire de Jérémie Bennejean [ 09/nov./06 15:12 ] |
|
La nouvelle version de RH as4 est en cours de telechargement. Attention une fois la maj faite on ne peut plus faire machine arriere... |
| Commentaire de François Le Lay [ 10/nov./06 11:21 ] |
| OK pour le passage en AS4. J'ai backupé le nécessaire. |
| Commentaire de François Le Lay [ 10/nov./06 11:36 ] |
| En fait il serait bien de procéder au backup de /home/bo sur disque dur sur une autrre machine. |
| Commentaire de Jérémie Bennejean [ 10/nov./06 11:40 ] |
|
Très bien, je vias mettre les données sur henriot. Je vais backuper /data1/home/bo Par contre je pense qu'il faut mieux stopper Bo durant le backup ? Quand puis-je faire cela ? |
| Commentaire de François Le Lay [ 10/nov./06 12:58 ] |
| Le tar.gz a fini a 12h15 |
| Commentaire de Jérémie Bennejean [ 10/nov./06 15:19 ] |
| J'ai déplacé les données |
| Commentaire de Jérémie Bennejean [ 10/nov./06 16:18 ] |
|
Les cd sont finis ont finis d'être telechargés |
| Commentaire de Jérémie Bennejean [ 10/nov./06 16:18 ] |
| Et en cours de gravure |
| Commentaire de Patrice Boulanger [ 15/nov./06 14:53 ] |
|
Suite à la discussion avec Agathe, nous allons procéder ainsi: 1. l'exploit crée un compte "bo" sur le serveur Giraud (192.168.1.4) 1bis. l'exploit install l'arborescence /appli et /data + JDK sur Giraud 2. le B.I. installe la nouvelle version de BO sur Giraud et importe les données depuis Pérignon 3. dès que l'install est validé, l'exploit met à jour Pérignon en RH AS 4 Update 4 4. le B.I. ré-importe les données depuis Giraud. NB: Pérignon est une architecture 32 bits, Giraud est une architecture 64 bits. Ca ne devrait pas être gênant. |
| Commentaire de François Le Lay [ 15/nov./06 17:13 ] |
|
Je viens de vérifier la doc BO: (1) Linux support is limited strictly to the 32-bit versions of Linux operating on either 32 or 64-bit (x86) AMD/Intel chipsets. BusinessObjects Enterprise software for Linux is not warranted or supported for use on other chipsets. Donc étant donné que giraud est monté avec un noyau 64 bits, il faut passer sur une autre machine, toujours en AS4 mais avec une configuration proc 64+noyau 32 bits ou proc 32/noyau 32. |
| Commentaire de François Le Lay [ 15/nov./06 17:18 ] |
| Il faut également installer le package compat-libstdc++-33-3.2.3-47.3.i386.rpm |
| Commentaire de Jérémie Bennejean [ 15/nov./06 17:45 ] |
| Comme vu avec Patrice, on passe sur Salon |
| Commentaire de Jérémie Bennejean [ 15/nov./06 17:51 ] |
|
Le user bo est créé à l'identique le group dba aussi Le home est en cours de copie |
| Commentaire de Jérémie Bennejean [ 16/nov./06 11:30 ] |
| compat-libstdc++-33-3.2.3-47.3.i386.rpm installé |
| Commentaire de François Le Lay [ 16/nov./06 11:56 ] |
|
Par ailleurs, un home oracle est nécessaire sur salon. Copie de lelay@ruinart:~/oracle.tar.gz dans salon:/home et mise en place des librairies client oracle, tnsnames et .bashrc |
| Commentaire de François Le Lay [ 16/nov./06 11:57 ] |
|
le user bo a le groupe 520 dans /etc/passwd lui affecter le groupe dba:501 serait plus adéquat? et par ailleurs passer un chgrp récursif sur le home bo. |
| Commentaire de Jérémie Bennejean [ 16/nov./06 12:06 ] |
| Rajout du group oinstall avec le gid 520 su salon |
| Commentaire de Agathe Remy [ 22/nov./06 14:37 ] |
|
Jérémie, Nous avons terminé la migration sur salon : perignon t'appartient. Sachant que nous ne pouvons plus faire de mise en production tant que perignon sera en cours de migration, ce serait bien que la migration RedHat soit faite d'ici lundi 27 novembre. Merci:-) Agathe |
| Commentaire de Jérémie Bennejean [ 23/nov./06 17:12 ] |
| Vu avec Agathe et Patrice, Perignon reste en AS3 et actif ainsi que salon. |
| Commentaire de Jérémie Bennejean [ 08/mars/07 16:03 ] |
|
abandonné. C'est brice qui va remplacer perignon |
[BIN-214] [Finance] : Ecart sur claims du mois d'octobre 06 Création: 08/nov./06 09:11 Mise à jour: 04/sept./08 18:43 Résolue: 04/sept./08 18:43 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Executive |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Philippe Favrot | Attribution: | Dalila Belkebir |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Synthèse claims.xls
|
| Pays: |
FRA - France
|
| Description |
|
Agathe, écart dans les données Titan et les données BO au niveau des claims pour l emois d'octovre ; par exemple : Titan Bo ZVRA : nbre 7 159 5 062 comm item annulées 30,7 k¿ 20,9 k¿ comm shipping annulées 7,7 k¿ 5,3 k¿ PVRA : nbre 1 669 1 185 buyer bonus 23,1 k¿ 16,1 k¿ PVZA : nbre 646 541 Merci Philippr |
| Commentaires |
| Commentaire de Philippe Favrot [ 22/nov./06 19:34 ] |
|
je complète ce Jira suite à notre réunion de ce soir. Par ailleurs, des écarts existent sur les données historiques (période 2001 / 30 juin 2006) au niveau des ZVRA et des PVRA. Voir le fichier joint ; 2 onglets "synthèse ZVRA" et "synthèse PVRA". Les écarts sont surlignés en orange. Philippe |
| Commentaire de Agathe Remy [ 05/déc./06 16:17 ] |
|
Les écarts étaient dus à 2 problèmes : - problème de mise à jour des items entre le 10/10/2006 et le 10/11/2006 : les données ont été mises à jour. - problème dans la condition sur la période de fermeture de la réclamation : nous devons attendre la fin de la migration BO pour corriger ce problème, à savoir fin de cette semaine. Cordialement, Agathe |
| Commentaire de Agathe Remy [ 12/déc./06 17:32 ] |
|
Les mises en production BI refonctionnent depuis ce matin (après deux semaines de panne):-) La condition sur la période de fermeture de la réclamation a donc été corrigée. Cordialement, Agathe |
| Commentaire de Philippe Favrot [ 21/déc./06 15:53 ] |
| voir écart sur le passé |
| Commentaire de Philippe Favrot [ 26/déc./06 08:33 ] |
|
Agathe, merci de laisser une priorité critique à ce Jira. En effet tant que les écarts sur le passé n'ont pas été expliqués, je ne peux pas utiliser ce rapport pour enregistrer les claims dans les comptes ; je continue donc à utiliser Titan, ce qui n'est pas satisfaisant car on a vu que Titan ne reprenait pas l'intégralité des éléments constuituant les claims. Merci Philippe |
| Commentaire de Agathe Remy [ 25/juil./08 20:41 ] |
|
Philippe, Qu'en est-il de ce JIRA? Agathe |
| Commentaire de Agathe Remy [ 04/sept./08 15:05 ] |
|
Bonjour Philippe, Dernière relance avant fermeture:-) Peux-tu me confirmer la clôture de ce JIRA? Merci. Agathe |
| Commentaire de Philippe Favrot [ 04/sept./08 18:39 ] |
|
Hello, à clôturer bien évidemment. Merci Philippe |
[APP-13926] Mail Abandonniste :: Enquête en ligne Création: 29/nov./06 14:47 Mise à jour: 25/juin/07 18:47 Résolue: 12/déc./06 09:33 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Mails, News Letters |
| Affecte la/les version(s): | 11.0.0 (Merge et Maintenance) |
| Version(s) corrigée(s): | 11.0.0 (Merge et Maintenance) |
| Type: | Nouvelle fonctionnalité | Priorité: | Mineur |
| Rapporteur: | Richard Dubois | Attribution: | Richard Dubois |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
abandonnistes-questionnaire-nvs_291106.doc
Planning_abandonniste_questionnaire_v0.2_light.mpp
|
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM archivés: | Abandonnistes |
| Description |
|
Bonjour, Le projet "Abandonnistes" est lancée ! Vous trouverez en pièce jointe une "mini spéc" (sur la base du doc de point d'entrée d'ALV) et une planning prévisonnel. Bonne journée @ tous |
| Commentaires |
| Commentaire de Younès Charrière [ 29/nov./06 15:06 ] |
| Passera post déploiement. |
| Commentaire de Richard Dubois [ 29/nov./06 15:50 ] |
|
Bonjour, Les libellés et les messages d'erreurs viennent d'être "franchisé". Rendez-vous sur http://websurveyor.net/wsb.dll/72568/enquete_priceminister.htm pour tester et avoir vos retours Bons tests :) |
| Commentaire de Richard Dubois [ 30/nov./06 16:26 ] |
|
Alex, concernant l'extraction des données BI, quels sont les champs dont tu aurais besoin ?? Avec Agathe, on a dèjà pensé à: user_id pseudo En vois-tu d'autres ?? Bonne fin de journée |
| Commentaire de Alexandra Viravaud [ 30/nov./06 18:00 ] |
| non ca me parait bien. |
| Commentaire de Richard Dubois [ 01/déc./06 09:04 ] |
|
Alexandra bonjour, Pour l'envoi avec Email Vision: 1 - Est-ce que la créa de la newsletter est prête ? 2- J'ai enfin la solution pour pouvoir recupérer l'id_user dans Websurveyor ! l'url que tu devras rajouter dans le mail sera de type http://websurveyor.net/wsb.dll/72568/enquete_priceminister.htm?WSB16=[user_ID] [user_ID] te sera fourni par Agathe Comme cela l'internaute reçoit le mail, il clique sur le lien (qui l'identifie aussi grace au user_ID) pour répondre au questionnaire. Lorsque via Websurveyor tu feras ton analyse, a l'extraction des données (soit au format txt ou csv), pour chaque ligne, tu auras donc un user_id qui te permettra de savoir qui a répondu. @ta dispo pour plus d'informations Bonne journée |
| Commentaire de Alexandra Viravaud [ 01/déc./06 10:38 ] |
|
la créa sera en principe prête ce soir. Alex |
| Commentaire de Younès Charrière [ 11/déc./06 18:04 ] |
| Les tests étaient concluants. Richard, peux tu résoudre ce jira si tout va bien de ton côté ? |
| Commentaire de Richard Dubois [ 12/déc./06 09:33 ] |
| L'equête est en ligne ! De bons retours, une mine d'information (beaucoup de commentaires pertinents). Merci à tous ! |
[EXP-2730] phaeton : reduire l'occupation des disques Création: 27/sept./06 14:46 Mise à jour: 25/juin/07 18:59 Résolue: 31/oct./06 11:48 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Justin Ziegler | Attribution: | Patrice Boulanger |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Voici ce qui sort d'une analyse de l'occupation disque de /data sur phaeton : Extrait de la commande "du -ks" : 4712 asconf 2992 sudmannm 1540 tmp.edouard 3008 grehalln 3412 tmp_gak 38580 jos 46976 klosekg 80728 pm_archpurge 80240 decpool 130 988 cnet 110 140 pmftpstock 170 748 pmfiletransfers 219 880 tmp 444 500 pmproductimport cnet : ne contient que de vieux fichiers !!! peut on le supprimer ? A voir avec Edouard ? peut on le comprimer ? tmp : j'ai l'impression que plein de choses peuvent etre supprimes tmp.edouard : on peut le virer ? A voir avec Edouard. decpool : demander au decisionnel de faire du menage ? /data/priceminister/pmproductimport/titelive_images /data/priceminister/pmproductimport/titelive /data/priceminister/pmproductimport/tf1video => peut bientot etre supprimé ? |
| Commentaires |
| Commentaire de Patrice Boulanger [ 27/sept./06 15:00 ] |
|
Etat initial: /dev/cciss/c0d0p7 13268456 9064472 3529972 72% /data |
| Commentaire de Patrice Boulanger [ 27/sept./06 15:01 ] |
|
Répertoire jos/: [adminpm@phaeton jos]$ ll total 38588 drwxrwxr-x 2 adminpm adminpm 4096 Dec 7 2005 . drwxr-xr-x 37 adminpm adminpm 8192 Sep 27 14:56 .. -rw-r--r-- 1 adminpm adminpm 13521 Nov 23 2005 log4j.xml -rw-r--r-- 1 adminpm adminpm 14369 Nov 23 2005 log4j.xml.20051123 -rw-r--r-- 1 adminpm adminpm 1272612 Dec 7 2005 NMCE.tgz -rw-rw-r-- 1 adminpm adminpm 38144308 Nov 24 2005 queryTxn.log.20051122.1151.gz Fichiers de logs de presque 1 an => supprimés. |
| Commentaire de Patrice Boulanger [ 27/sept./06 15:02 ] |
| pour decpool j'ai demandé à Agathe de me donner un état. |
| Commentaire de Patrice Boulanger [ 27/sept./06 15:09 ] |
|
Je propose aussi de cleaner le répertoire /data/mrtg: [adminpm@phaeton mrtg]$ du -sh * 4.0K cron.mrtg 4.0K cron.scr 1.2M etc 19M livraison 0 minitord 1.8M minitord-0.11.10 1.8M minitord-0.12.4 1.8M minitord-0.12.6 1.8M minitord-0.12.7 6.3M minitord.orig 1.3M perl 4.0K profile.rc 5.1M tmp 11M var En particulier, les anciennes versions de minitord: [adminpm@phaeton mrtg]$ cd livraison/ [adminpm@phaeton livraison]$ ll total 19256 drwxrwxr-x 2 mrtg adminpm 4096 Jun 30 14:40 . drwxr-xr-x 14 mrtg adminpm 4096 Jun 30 14:42 .. -rw-rw-r-- 1 mrtg adminpm 79230 Aug 18 2005 minitord-0.0.15.tar.gz -rw-r--r-- 1 mrtg adminpm 89267 Aug 12 2005 minitord-0.0.21.tar.gz -rw-r--r-- 1 mrtg adminpm 89542 Aug 19 2005 minitord-0.0.27.tar.gz -rw-r--r-- 1 mrtg adminpm 96562 Aug 24 2005 minitord-0.0.28.tar.gz -rw-r--r-- 1 mrtg adminpm 110220 Aug 26 2005 minitord-0.0.29.tar.gz -rw-r--r-- 1 mrtg adminpm 110970 Aug 31 2005 minitord-0.0.30.tar.gz -rw-r--r-- 1 mrtg adminpm 166307 May 5 11:09 minitord-0.10.1.tar.gz -rw-r--r-- 1 mrtg adminpm 166331 May 9 11:55 minitord-0.10.2.tar.gz -rw-r--r-- 1 mrtg adminpm 167070 May 10 17:48 minitord-0.10.3.tar.gz -rw-r--r-- 1 mrtg adminpm 167210 May 12 11:45 minitord-0.10.4.tar.gz -rw-r--r-- 1 mrtg adminpm 167705 May 12 14:26 minitord-0.10.5.tar.gz -rw-r--r-- 1 mrtg adminpm 167700 May 12 14:37 minitord-0.10.6.tar.gz -rw-r--r-- 1 mrtg adminpm 161791 Nov 22 2005 minitord-0.1.10.tar.gz -rw-r--r-- 1 mrtg adminpm 169664 Jun 12 10:42 minitord-0.11.10.tar.gz -rw-r--r-- 1 mrtg adminpm 156429 Nov 24 2005 minitord-0.1.11.tar.gz -rw-r--r-- 1 mrtg adminpm 167702 May 12 14:40 minitord-0.11.1.tar.gz -rw-r--r-- 1 mrtg adminpm 156438 Nov 24 2005 minitord-0.1.12.tar.gz -rw-r--r-- 1 mrtg adminpm 167722 May 12 15:31 minitord-0.11.2.tar.gz -rw-r--r-- 1 mrtg adminpm 156451 Nov 24 2005 minitord-0.1.13.tar.gz -rw-r--r-- 1 mrtg adminpm 168086 May 15 15:02 minitord-0.11.3.tar.gz -rw-r--r-- 1 mrtg adminpm 227000 Nov 29 2005 minitord-0.1.14.tar.gz -rw-r--r-- 1 mrtg adminpm 168110 May 16 10:40 minitord-0.11.4.tar.gz -rw-r--r-- 1 mrtg adminpm 226778 Nov 29 2005 minitord-0.1.15.tar.gz -rw-r--r-- 1 mrtg adminpm 168588 May 17 16:28 minitord-0.11.5.tar.gz -rw-r--r-- 1 mrtg adminpm 169503 Jun 5 15:15 minitord-0.11.6.tar.gz -rw-r--r-- 1 mrtg adminpm 210641 Dec 2 2005 minitord-0.1.17.tar.gz -rw-r--r-- 1 mrtg adminpm 169532 Jun 5 17:15 minitord-0.11.7.tar.gz -rw-r--r-- 1 mrtg adminpm 203768 Dec 2 2005 minitord-0.1.18.tar.gz -rw-r--r-- 1 mrtg adminpm 169532 Jun 6 11:19 minitord-0.11.8.tar.gz -rw-r--r-- 1 mrtg adminpm 203792 Dec 19 2005 minitord-0.1.19.tar.gz -rw-r--r-- 1 mrtg adminpm 169527 Jun 7 11:25 minitord-0.11.9.tar.gz -rw-r--r-- 1 mrtg adminpm 121387 Sep 12 2005 minitord-0.1.1.tar.gz -rw-r--r-- 1 mrtg adminpm 204099 Dec 19 2005 minitord-0.1.20.tar.gz -rw-r--r-- 1 mrtg adminpm 206808 Dec 19 2005 minitord-0.1.21.tar.gz -rw-r--r-- 1 mrtg adminpm 170343 Jun 14 10:35 minitord-0.12.1.tar.gz -rw-r--r-- 1 mrtg adminpm 207353 Dec 22 2005 minitord-0.1.22.tar.gz -rw-r--r-- 1 mrtg adminpm 170366 Jun 15 10:44 minitord-0.12.2.tar.gz -rw-r--r-- 1 mrtg adminpm 209313 Dec 23 2005 minitord-0.1.23.tar.gz -rw-r--r-- 1 mrtg adminpm 170372 Jun 19 14:28 minitord-0.12.3.tar.gz -rw-r--r-- 1 mrtg adminpm 209346 Dec 26 2005 minitord-0.1.24.tar.gz -rw-r--r-- 1 mrtg adminpm 170332 Jun 21 11:18 minitord-0.12.4.tar.gz -rw-r--r-- 1 mrtg adminpm 171253 Jun 22 10:44 minitord-0.12.5.tar.gz -rw-r--r-- 1 mrtg adminpm 209611 Dec 26 2005 minitord-0.1.26.tar.gz -rw-r--r-- 1 mrtg adminpm 171177 Jun 26 10:04 minitord-0.12.6.tar.gz -rw-r--r-- 1 mrtg adminpm 210595 Dec 28 2005 minitord-0.1.27.tar.gz -rw-r--r-- 1 mrtg adminpm 172171 Jun 30 14:42 minitord-0.12.7.tar.gz -rw-r--r-- 1 mrtg adminpm 210594 Dec 28 2005 minitord-0.1.29.tar.gz -rw-r--r-- 1 mrtg adminpm 120882 Oct 5 2005 minitord-0.1.2.tar.gz -rw-r--r-- 1 mrtg adminpm 210630 Dec 28 2005 minitord-0.1.30.tar.gz -rw-r--r-- 1 mrtg adminpm 210637 Jan 2 2006 minitord-0.1.31.tar.gz -rw-r--r-- 1 mrtg adminpm 212790 Jan 4 2006 minitord-0.1.32.tar.gz -rw-r--r-- 1 mrtg adminpm 213826 Jan 4 2006 minitord-0.1.33.tar.gz -rw-r--r-- 1 mrtg adminpm 220056 Jan 9 2006 minitord-0.1.34.tar.gz -rw-r--r-- 1 mrtg adminpm 225323 Jan 16 2006 minitord-0.1.36.tar.gz -rw-r--r-- 1 mrtg adminpm 129737 Oct 11 2005 minitord-0.1.3.tar.gz -rw-r--r-- 1 mrtg adminpm 136457 Oct 18 2005 minitord-0.1.4.tar.gz -rw-r--r-- 1 mrtg adminpm 131940 Oct 19 2005 minitord-0.1.5.tar.gz -rw-rw-r-- 1 mrtg adminpm 137078 Nov 17 2005 minitord-0.1.8.tar.gz -rw-r--r-- 1 mrtg adminpm 195930 Jan 19 2006 minitord-0.2.3.tar.gz -rw-r--r-- 1 mrtg adminpm 195939 Jan 19 2006 minitord-0.2.4.tar.gz -rw-r--r-- 1 mrtg adminpm 196950 Jan 20 2006 minitord-0.2.5.tar.gz -rw-r--r-- 1 mrtg adminpm 196911 Jan 20 2006 minitord-0.2.6.tar.gz -rw-r--r-- 1 mrtg adminpm 196932 Jan 20 2006 minitord-0.2.7.tar.gz -rw-r--r-- 1 mrtg adminpm 196825 Jan 30 2006 minitord-0.2.8.tar.gz -rw-r--r-- 1 mrtg adminpm 197195 Jan 30 2006 minitord-0.3.1.tar.gz -rw-r--r-- 1 mrtg adminpm 184214 Jan 30 2006 minitord-0.3.2.tar.gz -rw-r--r-- 1 mrtg adminpm 184255 Jan 30 2006 minitord-0.3.3.tar.gz -rw-r--r-- 1 mrtg adminpm 184270 Jan 30 2006 minitord-0.3.4.tar.gz -rw-r--r-- 1 mrtg adminpm 192750 Feb 2 2006 minitord-0.3.5.tar.gz -rw-r--r-- 1 mrtg adminpm 134149 Feb 3 2006 minitord-0.3.7.tar.gz -rw-r--r-- 1 mrtg adminpm 132712 Feb 6 2006 minitord-0.4.0.tar.gz -rw-r--r-- 1 mrtg adminpm 136622 Feb 13 2006 minitord-0.4.10.tar.gz -rw-r--r-- 1 mrtg adminpm 132681 Feb 6 2006 minitord-0.4.1.tar.gz -rw-r--r-- 1 mrtg adminpm 132674 Feb 6 2006 minitord-0.4.2.tar.gz -rw-r--r-- 1 mrtg adminpm 132679 Feb 6 2006 minitord-0.4.3.tar.gz -rw-r--r-- 1 mrtg adminpm 132685 Feb 6 2006 minitord-0.4.5.tar.gz -rw-r--r-- 1 mrtg adminpm 135544 Feb 8 2006 minitord-0.4.6.tar.gz -rw-r--r-- 1 mrtg adminpm 136848 Feb 8 2006 minitord-0.4.7.tar.gz -rw-r--r-- 1 mrtg adminpm 144831 Feb 20 2006 minitord-0.5.0.tar.gz -rw-r--r-- 1 mrtg adminpm 146873 Feb 22 2006 minitord-0.6.0.tar.gz -rw-r--r-- 1 mrtg adminpm 147290 Feb 22 2006 minitord-0.6.1.tar.gz -rw-r--r-- 1 mrtg adminpm 147628 Feb 23 2006 minitord-0.6.2.tar.gz -rw-r--r-- 1 mrtg adminpm 147907 Mar 6 2006 minitord-0.6.3.tar.gz -rw-r--r-- 1 mrtg adminpm 148496 Mar 6 2006 minitord-0.6.4.tar.gz -rw-r--r-- 1 mrtg adminpm 148736 Mar 8 2006 minitord-0.6.5.tar.gz -rw-r--r-- 1 mrtg adminpm 155011 Apr 3 17:18 minitord-0.7.10.tar.gz -rw-r--r-- 1 mrtg adminpm 154995 Apr 5 15:40 minitord-0.7.11.tar.gz -rw-r--r-- 1 mrtg adminpm 155168 Apr 6 10:49 minitord-0.7.12.tar.gz -rw-r--r-- 1 mrtg adminpm 152055 Mar 20 2006 minitord-0.7.2.tar.gz -rw-r--r-- 1 mrtg adminpm 153337 Mar 28 2006 minitord-0.7.3.tar.gz -rw-r--r-- 1 mrtg adminpm 153342 Mar 28 2006 minitord-0.7.4.tar.gz -rw-r--r-- 1 mrtg adminpm 153363 Mar 28 2006 minitord-0.7.5.tar.gz -rw-r--r-- 1 mrtg adminpm 153881 Mar 30 12:41 minitord-0.7.6.tar.gz -rw-r--r-- 1 mrtg adminpm 154703 Mar 31 11:50 minitord-0.7.7.tar.gz -rw-r--r-- 1 mrtg adminpm 154984 Apr 3 15:39 minitord-0.7.8.tar.gz -rw-r--r-- 1 mrtg adminpm 155018 Apr 3 16:19 minitord-0.7.9.tar.gz -rw-r--r-- 1 mrtg adminpm 155170 Apr 6 11:42 minitord-0.8.0.tar.gz -rw-r--r-- 1 mrtg adminpm 155544 Apr 6 14:22 minitord-0.8.1.tar.gz -rw-r--r-- 1 mrtg adminpm 156246 Apr 7 12:26 minitord-0.8.2.tar.gz -rw-r--r-- 1 mrtg adminpm 157422 Apr 11 10:54 minitord-0.8.3.tar.gz -rw-r--r-- 1 mrtg adminpm 157468 Apr 11 11:41 minitord-0.8.4.tar.gz -rw-r--r-- 1 mrtg adminpm 157526 Apr 11 12:01 minitord-0.8.5.tar.gz -rw-r--r-- 1 mrtg adminpm 157492 Apr 11 16:41 minitord-0.8.6.tar.gz -rw-r--r-- 1 mrtg adminpm 158757 Apr 14 15:11 minitord-0.9.0.tar.gz -rw-r--r-- 1 mrtg adminpm 166130 May 3 11:03 minitord-0.9.10.tar.gz -rw-r--r-- 1 mrtg adminpm 166258 May 4 16:08 minitord-0.9.11.tar.gz -rw-r--r-- 1 mrtg adminpm 166265 May 4 17:49 minitord-0.9.12.tar.gz -rw-r--r-- 1 mrtg adminpm 159370 Apr 14 17:42 minitord-0.9.2.tar.gz -rw-r--r-- 1 mrtg adminpm 159501 Apr 19 16:50 minitord-0.9.3.tar.gz -rw-r--r-- 1 mrtg adminpm 159955 Apr 19 17:38 minitord-0.9.4.tar.gz -rw-r--r-- 1 mrtg adminpm 159968 Apr 19 18:29 minitord-0.9.5.tar.gz -rw-r--r-- 1 mrtg adminpm 160933 Apr 24 15:31 minitord-0.9.6.tar.gz -rw-r--r-- 1 mrtg adminpm 160991 Apr 26 17:56 minitord-0.9.7.tar.gz -rw-r--r-- 1 mrtg adminpm 161297 Apr 28 14:19 minitord-0.9.8.tar.gz -rw-r--r-- 1 mrtg adminpm 164770 May 3 10:48 minitord-0.9.9.tar.gz |
| Commentaire de Patrice Boulanger [ 27/sept./06 15:14 ] |
|
tmp.edouard et cnet => mail à Edouard. Pour decpool, le BI met des fichiers importants pour eux dans ce répertoire. Vu avec Agathe pour faire le ménage et peut-être déplacer le contenu (sur tellus, latone, titan ?) |
| Commentaire de Patrice Boulanger [ 27/sept./06 15:16 ] |
| Pour /data/priceminister/klosekg, mail envoyé à Gaël. |
| Commentaire de Patrice Boulanger [ 28/sept./06 14:36 ] |
| Les répertoires jos, klosekg et decpool ont été vidés. |
| Commentaire de Justin Ziegler [ 28/sept./06 16:43 ] |
|
Cool ! Quelle est le prochain candidat ? |
| Commentaire de Patrice Boulanger [ 31/oct./06 11:48 ] |
|
L'espace disque utilisé sur /data sur phaeton est descendu à 56%. Nous avons supprimé les anciennes versions du contenu statique de l'application. |
[DEC-511] intégration des nouveaux contacts et requalification de la BDD PM suite au jeu "mission super vendeur" Création: 30/nov./06 14:50 Mise à jour: 14/sept./07 15:25 Résolue: 16/janv./07 15:09 |
|
| Etat: | Fermé |
| Projet: | Reporting |
| Composants: | Partners |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Bloquant |
| Rapporteur: | Thomas Beylot | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
tablecorrespondance.xls
|
||||||||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Description |
|
Le jeu super vendeur se finit le 29/12. A l'issue de ce jeu il faudra attribuer les chances supplémentaires au joueurs ayant déposé une annonce lors du jeu (ceci fait l'objet d'un autre jira) et aussi intégrer les nouveaux contacts suite au jeu et actualiser le profil des pricemembers. Pour être au point il faudrait bien checker la forme du fichier que 1000 mercis m'enverrait ? merci ! thomas. |
| Commentaires |
| Commentaire de Agathe Remy [ 01/déc./06 16:20 ] |
|
Thomas, Voici le format du fichier que doit nous fournir 1000Mercis: fichier CSV (séparateur ";") email;nom;prenom;adresse1;adresse2;cp;ville;pays;IS_PARTNER_SUBSCRIBER;IS_CULTURAL_SUBSCRIBER;IS_HIGHTECH_SUBSCRIBER;IS_HOUSE_SUBSCRIBER Cordialement, Agathe |
| Commentaire de Edouard Laurent [ 04/déc./06 13:43 ] |
|
email;prenom;nom;IS_CULTURAL_SUB;TRACKING_ID;;;IS_PARTNER_SUB;IS_HIGHTECH_SUB;IS_HOUSE_SUB Le format du fichier devrait plutot ressembler a ca Merci Edouard |
| Commentaire de Thomas Beylot [ 09/janv./07 12:20 ] |
|
je viens de demander le bon format pour le fichier à 1000mercis. en attendant je vais de ce pas attacher la table de correspondance à ce jira. thomas. |
| Commentaire de Edouard Laurent [ 16/janv./07 15:09 ] |
| L'integration est terminé : 161 874 nouveaux contacts dans le cadre de ce jeu |
| Commentaire de Thomas Beylot [ 16/janv./07 16:21 ] |
|
une ptite question pour finir: sais-tu combien de ces contacts sont opt-in ? |
| Commentaire de Edouard Laurent [ 16/janv./07 16:26 ] |
| C'est plutot une demande BI, essaye de voir ca avec Agathe |
[BIN-242] [Finance] : écart Titan / BO sur mouvements PMV Création: 11/déc./06 14:36 Mise à jour: 07/janv./08 18:09 Résolue: 02/janv./08 11:53 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Executive |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Philippe Favrot | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour, écart entre les chiffres issus de Titan (operation report) et BO (Daily mvt PMV) pour la journée du 24 novembre concernant le type de mouvement "Credit_BO" : Titan : 11 715,21 euros BO : 12 722,42 euros Philippe |
| Commentaires |
| Commentaire de Agathe Remy [ 14/déc./06 12:22 ] |
|
En effet, dans le rapport de Titan ne sont pas prise en comptes les opérations non associés à une cause : 2006/11/24;CREDIT_BO;;1007,21 2006/11/24;CREDIT_BO;Cashstore;84,2 2006/11/24;CREDIT_BO;Remboursement;11225,36 2006/11/24;CREDIT_BO;autre crédit;364,35 2006/11/24;CREDIT_BO;Chèque retourné;41,3 Le différence correspond donc au montant des opérations sans cause. Cordialement, Agathe |
| Commentaire de Philippe Favrot [ 15/déc./06 14:49 ] |
|
Agathe, tu peux m'en dire plus sur ces 1 007,21 euros de crédit PM sans cause : détail par pseudo... En fait ce serait la première fois que ce cas de figure se produit puisque jusqu'alors il n'y a jamais eu d'écart Titan / BO. Merci Philippe |
| Commentaire de Agathe Remy [ 15/déc./06 15:36 ] |
|
Il s'agit d'une operation unique : 10552 En fait, jusqu'au 25 juin 2004 les opérations n'avaient pas de causes associées. A partir du 28/06/2004, toutes les opérations sont associées à une cause. L'opération 10552 a été créée le 08/11/2002 pour le user account id 458071 et a été modifiée le 24/11/2006. En revanche, je n'ai aucun moyen de savoir en quoi a consisté la modification du 24 novembre dernier : il n'y a aucun évènement associé. Cordialement, Agathe |
| Commentaire de Philippe Favrot [ 19/déc./06 11:50 ] |
|
Agathe, en fait, aucun commentaire n'était renseigné au niveau de ce mouvement du 08/11/2002 donc on ne savait pas ce que c'était. Steven a donc ajouté un commentaire en date du 24/11/2006 ; en revanche il n'y a eu aucune modification de la date de finalisation de ce mouvement. Donc l'ajout de ce commentaire aurait du n'avoir aucun impact sur le rapport détaillant les mouvements affectant les PMV : or on constate que : - les mouvements du 08/11/02 (credit_BO) sont maintenant de 54,20 ¿ vs 1 061,41 ¿ avant la modif ; - les mouvements du 24/11/06 (credit_BO) reprennent cette opération. Il doit donc y avoir un problème sur les dates retenues pour élaborer ce rapport. Peux tu vérifier. Merci Philippe |
| Commentaire de Agathe Remy [ 21/déc./06 11:26 ] |
|
Philippe, Dans le rapport que tu as défini avec MEZ, vous vous basez sur la change date de l'opération, donc sa date de dernière mise à jour. Je pense qu'il aurait fallu se baser sur la date de création du mouvement. Mais cela fait partie des sujets que je voulais aborder avec toi lors de notre point sur le BI Espagne cet aprem. Cordialement, Agathe |
| Commentaire de Agathe Remy [ 03/août/07 17:16 ] |
|
Philippe, Peut-on fermer ce JIRA? Merci:-) Agathe |
| Commentaire de Agathe Remy [ 02/janv./08 11:53 ] |
|
Philippe, Peut-on fermer ce JIRA? Merci:-) Agathe |
| Commentaire de Philippe Favrot [ 07/janv./08 17:32 ] |
|
Agathe, tu peux effectivement fermer ce Jira. Merci :-) Philippe |
[BIN-425] [BackOffice] : Filtre Commit-Closing<1 (univers item) Création: 01/avr./08 16:08 Mise à jour: 23/avr./08 10:18 Résolue: 21/avr./08 15:05 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | BackOffice |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Cedric Favero | Attribution: | Florian Ambrosi |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
screenshot-1.jpg
|
| Pays: |
FRA - France
|
| Description |
|
J'aurais bien eu besoin de ce petit filtre pour etayer nos rapports de transactions entre comptes. Par contre j'ai l'impression qu'il ne fonctionne pas correctement puisqu'il me retourne des articles dont le délai entre les statut committed et closed est de plus d'1 jour. Est-ce que ce ne serait pas plutot CLOSING DATE - COMMIT DATE dans la requete ? Merci. |
| Commentaires |
| Commentaire de Agathe Remy [ 01/avr./08 16:12 ] |
|
Bonjour Cédric, Peux-tu me donner le nom exact et le chemin d'accès du rapport dont il s'agit? Merci. Agathe |
| Commentaire de Cedric Favero [ 01/avr./08 16:17 ] |
|
C'est un rapport que je suis en train de faire Dans Favoris\Cedric "Fraudes transactions vendeur/acheteur" , ma requete 10 |
| Commentaire de Agathe Remy [ 15/avr./08 12:20 ] |
|
Bonjour Cédric, Peux-tu me donner un exemple d'article renvoyé par la requête qui te semble ne pas correspondre au critère de sélection? Sinon, pour information, les dates stockées dans BI sont arrondies au jour et ne stockent pas les heures, minutes et secondes (pour des questions de volumétrie). Ainsi, la date de confirmation du vendeur stockée dans BI sera le 15/04/2008 00h00mn00sec que le vendeur ait confirmé la vente à 01h01mn01sec ou 23h59mn59sec. Ainsi, faire un filtre pour évaluer un délai inférieur à 1 jour ne me semble par pertinent avec de telles données (sans le détail des heures, minutes et secondes). Si le besoin est fort, nous pouvons mettre à jour ces dates afin d'intégrer les heures, minutes et secondes, mais pour cela, il nous faut une justification business parce que cette évolution demande plusieurs jours de développement. Cordialement, Agathe |
| Commentaire de Cedric Favero [ 15/avr./08 14:32 ] |
| voici la requete telle qu'est faite (cf capture) |
| Commentaire de Cedric Favero [ 15/avr./08 14:38 ] |
|
etr si on prend certains articles retournés, il ne
remplissent pas la condition 1 jour maxi entre les états committed et
closed ex des premiers articles retournés: http://bo.priceminister.com/purchase_back?action=itemview&itemid=79533326 http://bo.priceminister.com/purchase_back?action=itemview&itemid=79534362 |
| Commentaire de Cedric Favero [ 15/avr./08 14:41 ] |
| je n'ai pas besoin des heures , minutes , secondes :-) |
| Commentaire de Agathe Remy [ 15/avr./08 15:26 ] |
|
Après mure réflexion, le problème vient du fait que ta condition est construite à l'envers?! En effet, la date de confirmation du vendeur étant toujours antérieure à la date de clôture de l'article, leur différence est toujours négative donc inférieure à 1 jour... Cette condition prédéfinie est donc erronées. Je le fait donc corriger. Agathe |
| Commentaire de Cedric Favero [ 15/avr./08 15:31 ] |
|
c'est pour çà que je disais , n'est-ce pas plutot:?: CLOSING DATE moins COMMIT DATE inferiieure à 1 |
| Commentaire de Cedric Favero [ 22/avr./08 09:55 ] |
|
Je ne vois pas le filtre modifié dans l'univers Purchase. Il est où? Le commit-closing<1 n'a pas changé. Merci. |
| Commentaire de Agathe Remy [ 22/avr./08 10:00 ] |
|
Cédric, La modification a été apportée pour l'instant en Développement (d'où le nom de l'univers "DEV - ITEM" signalé par Florian). Après validation, nous passerons la modification en Production. Agathe |
| Commentaire de Cedric Favero [ 22/avr./08 10:05 ] |
|
Ok dac, contraitement aux APP , çà ne m'apparaissait pas clairement , avec une version cible et tout.. Merci. |
| Commentaire de Florian Ambrosi [ 22/avr./08 17:39 ] |
|
Agathe, C'est déployé sur le serveur en production. Florian |
| Commentaire de Cedric Favero [ 23/avr./08 10:14 ] |
|
C'est bon, çà marche nickel. Merci. |
[EXP-4215] [Espagne] : Demande de rapport : valeur client par tracking Espagne Création: 01/févr./08 12:31 Mise à jour: 25/juin/08 17:29 Résolue: 25/juin/08 17:29 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Rapport |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Charles Decaux | Attribution: | Patrick Pereira |
| Résolution: | Aucune correction envisagée | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ESP - Espagne
|
| Description |
|
Bonjour, L'indicateur principal des partenariats est aujourd'hui le coût d'acquisition client sur l'Espagne Afin de déterminer si les nouveaux clients sont "rentables" on souhaite connaître la valeur client par tracking. Il nous faudrait donc un rapport indiquant, par tracking et par groupe de tracking la valeur client sur les 6 derniers mois et sur les 12 derniers mois. Merci Charles |
| Commentaires |
| Commentaire de Agathe Remy [ 05/févr./08 15:07 ] |
|
Charles, Peux-tu nous donner le chemin d'accès dans l'intranet du ou des rapports BI ou titan au(x)quel(s) tu fait allusion? Merci:-) Agathe |
| Commentaire de Charles Decaux [ 05/févr./08 17:03 ] |
|
http://intra.priceminister.com/stats/reports/confid/Suivi_Acheteurs/ |
| Commentaire de Agathe Remy [ 07/févr./08 10:19 ] |
|
Patrick, Comme convenu, je te réattribue ce JIRA. A voir s'il vraiment nécessaire de produire ces rapports. Les requêtes de génération des rapports sur titan sont les suivantes : /data/priceminister/reporting/platform/prod/sql/sources/executive/report_suivi_acheteurs.sql /data/priceminister/reporting/platform/prod/sql/sources/executive/report_premier_achat_avec_coupon.sql /data/priceminister/reporting/platform/prod/sql/sources/executive/report_premier_achat_sans_coupon.sql /data/priceminister/reporting/platform/prod/sql/sources/executive/report_premier_achat_non_vendeur.sql /data/priceminister/reporting/platform/prod/sql/sources/executive/report_premier_achat_vendeur.sql Pour se générer, ces rapports utilisent une vue matérialisée dont tu trouveras le script également sur titan : /u01/priceminister/priceminister/reporting/oneshot/Executive/new_buyer_mv.sql Agathe |
| Commentaire de Agathe Remy [ 07/févr./08 10:21 ] |
|
Charles, Ces rapports constituent ce que nous appelons la life time value. En revanche, en aucun cas ils ne donnent d'information par tracking ou groupe de tracking. Es-tu sûr qu'il s'agit de ces rapports? Agathe |
| Commentaire de Charles Decaux [ 08/févr./08 09:39 ] |
|
Effectivement, cela ne correspond pas à ce que je souhaite. Cependant cela peut me servir pour calculer la LTV globale, indépendemment du tracking. C'est déjà ca. Merci :-) |
| Commentaire de Patrick Pereira [ 13/févr./08 16:12 ] |
|
Mettre en place les rapports sur l'Espagne signifie une charge de travail pour moi et pour la base. Si ces rapports n'ont pas une réelle utilité, autant ne pas le faire. Pourriez-vous clairement identifier vos réels besoin ? Merci. |
Mise en oeuvre EVANDRE
(EXP-3568)
|
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Sous-tâche | Priorité: | Mineur |
| Rapporteur: | Jérémie Bennejean | Attribution: | Jérémie Bennejean |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
correspondance.xls
|
| Pays: |
FRA - France
|
| Commentaires |
| Commentaire de Jérémie Bennejean [ 31/mai/07 10:31 ] |
|
FRANCE WWW <VirtualHost 212.23.167.30:80> ServerName www.priceminister.com:80 ESPAGNE WWW <VirtualHost 212.23.167.36:80> DocumentRoot "/usr/local/apache/es/htdocs/pmweb/www.priceminister.es" ServerName www.priceminister.es:80 |
| Commentaire de Jérémie Bennejean [ 31/mai/07 10:49 ] |
|
Note pour moi, penser à demander à Jet de completer le /etc/hosts de evandre avec : 212.23.167.31 ofup.priceminister.com 212.23.167.31 virginmega.priceminister.com 212.23.167.31 m6net.priceminister.com 212.23.167.31 m6.priceminister.com 212.23.167.31 m6music.priceminister.com 212.23.167.31 m6game.priceminister.com 212.23.167.31 cinenow.priceminister.com 212.23.167.31 francemobiles.priceminister.com 212.23.167.31 jeuxvideo.priceminister.com 212.23.167.31 preview.priceminister.com 212.23.167.31 rfm.priceminister.com 212.23.167.31 freesurf.priceminister.com 212.23.167.31 croix-rouge.priceminister.com www.croix-rouge.priceminister.com 212.23.167.31 tiscalibe.priceminister.com 212.23.167.31 test.priceminister.com 212.23.167.31 europe2.priceminister.com 212.23.167.31 epik.priceminister.com 212.23.167.33 bo.priceminister.com bi.priceminister.com eglue.priceminister.com ig.priceminister.com 212.23.167.31 koobuycity.priceminister.com 212.23.167.31 mobilokaz.priceminister.com 212.23.167.35 www.radindesbois.com 212.23.167.37 pcdoccasions.vnunet.fr 212.23.167.32 occasion.camif.fr 212.23.167.34 occasion.presence-pc.com 212.23.167.31 mobilesachat.priceminister.com 212.23.167.38 bambinoccasion.priceminister.com 212.23.167.39 occasion.rueducommerce.fr occasion.rueducommerce.com 212.23.167.43 occasion.liberation.fr 212.23.167.36 www.priceminister.es 212.23.167.46 demo.priceminister.es 212.23.167.44 preview.priceminister.es 212.23.167.45 bo.priceminister.es 212.23.167.31 lycos-occasion.priceminister.com 212.23.167.31 laredoute-occasion.priceminister.com 212.23.167.31 journauxdumidi.priceminister.com 212.23.167.31 sfr.priceminister.com 212.23.167.31 nicematin.priceminister.com |
[DEC-599] bug sur les rapports SLTV Création: 11/juin/07 16:20 Mise à jour: 04/sept./08 14:57 Résolue: 04/sept./08 14:57 |
|
| Etat: | Fermé |
| Projet: | Reporting |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Thomas Beylot | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Quand on regarde de plus près les stats données par le
rapport
home/oracle/task_force_vendeur/tfv_2007-05/SLTV_ADVERT_2007-05.csv (mais
aussi home/oracle/task_force_vendeur/tfv_2007-05/SLTV_SALES_2007-05.csv
) on se rend compte que le rapport fait état de 5 347 nouveaux vendeurs
pour 37 303 annonces. Toutes les datas pour la promo de mai 07 ont l'air erronées, donc... :-( De plus quand on regarde dans le BO on voit que: - au 1er mai 2007 : 461971 - au 31 mai 2007 : 480276 soient 18 305 nouveaux vendeurs... ce qui semble plus logique quand regarde les chiffres précédents (16 000 en avril, 20 000 en mars)... Il doit donc s'être passé quelque chose ? thomas |
| Commentaires |
| Commentaire de Agathe Remy [ 04/sept./08 14:57 ] |
|
Suite au transfert des rapports SLTV dans BI, je ferme ce JIRA qui n'a plus lieu d'être... Agathe |
[APP-17620] Annonce auto frauduleuse visible par " articles mémorisées" Création: 23/août/07 14:54 Mise à jour: 29/oct./09 10:05 Résolue: 26/oct./09 12:20 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Auto (Statistiques) |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 56.0.0 (TX-J) |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Cedric Favero | Attribution: | Emeric Teil |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Classif1: | BP | ||||||||
| Classif2: | auto | ||||||||
| Projets PM archivés: | AUTO : Nettoyage | ||||||||
| Description |
|
Un utilisateur (carrie19) me signale une annonce frauduleuse au 21/08 Problème: l'annonce est périmée et le vendeur est en -2 depuis le 07/03/2007. Apparemment il est passé par articles mémorisés où l'annonce est toujours visible , il peut meme envoyer des messages au vendeur. Celà commence à etre vraiment dangereux ces problèmes de visibilité auto. |
| Commentaires |
| Commentaire de Cedric Favero [ 24/août/07 09:53 ] |
|
Autre cas pour exemple. Pseudo: drmisti ( Roumain) Son compte est en -2 depuis le 19/12/2006 et on nous signale aujourd'hui son annonce. Encore une fois elle était dans les articles mémorisés d'un acheteur (pseudo: topexpo) |
| Commentaire de Emeric Teil [ 10/déc./07 10:09 ] |
|
Du côté des "transactions", on a réalisé certaines
modifications sur le fonctionnement de la visibilité des annonces auto. Ainsi, lors de la création de l'annonce, la visibilité du vendeur est prise en compte (reportée sur l'annonce), ce qui n'était pas le cas auparavant (la visibilité de l'annonce dépendait uniquement de la conf produit). En complément à ces corrections, il reste certains dysfonctionnements à corriger, dont celui lié à ce JIRA. Ainsi, dans le cadre de l'Auto : -> Les coordonnées du vendeur sont liées à la fiche produit complément (et non pas uniquement à l'annonce) -> On affiche en Front la fiche produit complément (et non pas uniquement FP + DA) -> Les articles mémorisés ne portent pas sur les fiches produits mais sur les fiches produits compléments Sur le reste du site, lorsqu'un vendeur est passé en visibilité -2 : -> Ses annonces le sont également et ne sont donc plus visibles sur les fiches produits concernées -> Les articles mémorisés portant sur les fiches produit, ces annonces supprimées ne sont pas accessibles par ce biais Alors que sur l'auto : -> Les annonces passent bien en visibilité -2 -> Elles ne sont plus référencées par Fast et donc non accessibles dans la nav -> Elles restent cependant accessibles via les articles mémorisés et les utilisateurs ayant mémorisé cette "annonce" peuvent toujours acccéder aux coordonnées du vendeur ... Il semble donc y avoir différentes solutions : -> Lors de l'affichage d'une annonce ou d'une fiche produit complément, vérifier systématiquement que celle-ci a bien une visibilité >=0 -> Lors du passage d'une annonce en visibilité <0, supprimer toutes entrées de type "WISH" référençant le product_id concerné Je pense que cela concerne plutôt les équipe de Martin et/ou Edouard. |
| Commentaire de Nicolas Chauveau [ 11/déc./07 15:19 ] |
| A prioriser en CoPôle |
| Commentaire de Benoît Bourdon [ 21/avr./08 14:19 ] |
|
évolution : -> Lors de l'affichage d'une annonce ou d'une fiche produit complément, vérifier systématiquement que celle-ci a bien une visibilité >=0 |
[APP-19994] [Evenements] BO modifie la qualité de l'annonce, mais affiché Vendeur Création: 25/mars/08 19:06 Mise à jour: 24/sept./08 11:29 Résolue: 18/sept./08 08:42 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 19.2.1 |
| Version(s) corrigée(s): | 30.0.0 (CAT-D) |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Espérance Galouo-Lece | Attribution: | Dispatcher (Pôle CAT) |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
BO_modifie_qualité_mais_affiché_Vendeur.JPG
|
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM: | *** RESERVE *** |
| Classif1: | BO |
| Classif2: | événement annonce |
| Description |
|
Logs : 2008-03-25 18:55:23,460 INFO [P-Processor8] O:Non_identifié - >>> GET http://www.es.integ/advert_back?action=advertbackview&advertid=62900293 2008-03-25 18:55:23,514 INFO [P-Processor8] O:Non_identifié - <<< [54 ms] GET http://www.es.integ/advert_back?action=advertbackview&advertid=62900293 2008-03-25 18:55:38,151 INFO [P-Processor7] - connection timeout reached 2008-03-25 18:55:41,773 INFO [P-Processor8] O:Non_identifié - >>> POST http://www.es.integ/advert_back!action=advertback...&advertid=62900293&advqualitycode=20&comment=testInteg&cur rencyid=978&quantity=900&saleprice=5000.0&serialnumber=3168416841...&x=39&y=10 2008-03-25 18:55:41,818 INFO [P-Processor8] O:Non_identifié - (Status : 302) Redirecting to : /advert_back?action=advertbackview&advertid=62900293 2008-03-25 18:55:41,818 INFO [P-Processor8] O:Non_identifié - <<< [44 ms] POST http://www.es.integ/advert_back!action=advertback...&advertid=62900293&advqualitycode=20&comment=testI nteg¤cyid=978&quantity=900&saleprice=5000.0&serialnumber=3168416841...&x=39&y=10 2008-03-25 18:55:41,836 INFO [P-Processor7] O:Non_identifié - >>> GET http://www.es.integ/advert_back?action=advertbackview&advertid=62900293 2008-03-25 18:55:41,869 INFO [P-Processor7] O:Non_identifié - <<< [33 ms] GET http://www.es.integ/advert_back?action=advertbackview&advertid=62900293 2008-03-25 19:00:34,215 INFO [P-Processor7] O:Non_identifié - >>> POST http://www.es.integ/advert_back!action=advertback...&advertid=62900293&advqualitycode=40&comment=testInteg&cur rencyid=978&quantity=900&saleprice=5000.0&serialnumber=3168416841...&x=26&y=12 2008-03-25 19:00:34,271 INFO [P-Processor7] O:Non_identifié - (Status : 302) Redirecting to : /advert_back?action=advertbackview&advertid=62900293 2008-03-25 19:00:34,271 INFO [P-Processor7] O:Non_identifié - <<< [56 ms] POST http://www.es.integ/advert_back!action=advertback...&advertid=62900293&advqualitycode=40&comment=testI nteg¤cyid=978&quantity=900&saleprice=5000.0&serialnumber=3168416841...&x=26&y=12 2008-03-25 19:00:34,299 INFO [P-Processor8] O:Non_identifié - >>> GET http://www.es.integ/advert_back?action=advertbackview&advertid=62900293 2008-03-25 19:00:34,335 INFO [P-Processor8] O:Non_identifié - <<< [36 ms] GET http://www.es.integ/advert_back?action=advertbackview&advertid=62900293 2008-03-25 19:00:42,846 INFO [P-Processor7] O:Non_identifié - >>> POST http://www.es.integ/advert_back!action=advertback...&advertid=62900293&advqualitycode=10&comment=testInteg&cur rencyid=978&quantity=900&saleprice=5000.0&serialnumber=3168416841...&x=23&y=10 2008-03-25 19:00:42,871 INFO [P-Processor7] O:Non_identifié - (Status : 302) Redirecting to : /advert_back?action=advertbackview&advertid=62900293 2008-03-25 19:00:42,872 INFO [P-Processor7] O:Non_identifié - <<< [26 ms] POST http://www.es.integ/advert_back!action=advertback...&advertid=62900293&advqualitycode=10&comment=testI nteg¤cyid=978&quantity=900&saleprice=5000.0&serialnumber=3168416841...&x=23&y=10 2008-03-25 19:00:42,898 INFO [P-Processor8] O:Non_identifié - >>> GET http://www.es.integ/advert_back?action=advertbackview&advertid=62900293 2008-03-25 19:00:42,956 INFO [P-Processor8] O:Non_identifié - <<< [58 ms] GET http://www.es.integ/advert_back?action=advertbackview&advertid=62900293 |
| Commentaires |
| Commentaire de Nicolas Chauveau [ 26/mars/08 14:44 ] |
|
C'est une évolution. Cela nécessite un nouvel événement (=> impact BI). Est-ce nécessaire ? |
| Commentaire de Quentin de Chivré [ 26/mars/08 15:09 ] |
| On pourrait juste changer le libellé de l'venement, ca suffirait largement |
| Commentaire de Geneviève Beaujard [ 18/sept./08 08:42 ] |
|
Ajout de '(BO)' dans la description. Checking in advert/AdvertInput.java; /home/cvs/dev/source/src/com/babelstore/advert/AdvertInput.java,v <-- AdvertInput.java new revision: 1.98.136.1; previous revision: 1.98 done Checking in advert/back/AdvertBackUpdateAction.java; /home/cvs/dev/source/src/com/babelstore/advert/back/AdvertBackUpdateAction.java,v <-- AdvertBackUpdateAction.java new revision: 1.16.354.1; previous revision: 1.16 done Checking in stock/entity/Advert.java; /home/cvs/dev/source/src/com/babelstore/stock/entity/Advert.java,v <-- Advert.java new revision: 1.65.12.2; previous revision: 1.65.12.1 done |
NpF Vidéo FR
(CAT-104)
|
|
| Etat: | Résolu |
| Projet: | Paramétrage - Non Import |
| Composants: | Outils internes / Rapport |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | Marion Anfreville | Attribution: | Julien Sananikone |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
npf-video_bluray.xls
npf-video_dvd_autres_zones.xls
npf-video_dvdz1.xls
npf-video_dvdz2.xls
npf-video_hddvd.xls
npf-video_vhs.xls
|
| Pays: |
FRA - France
|
| Description |
|
Afin de permettre aux commerciaux de définir les filtres
pour l'univers VIDEO, il faut calculer le taux de remplissage (sur la
base de reporting) des types / mediums appartenant à cet univers. =>
voir doc pour calcul taux de remplissage http://ruinart.lan:4080/pricewiki/Wiki.jsp?page=TauxUtilisationAttribut
|
| Commentaires |
| Commentaire de Julien Sananikone [ 22/oct./07 10:47 ] |
| je vois pas la pièce jointe |
| Commentaire de Marion Anfreville [ 22/oct./07 17:33 ] |
| pas de pj, juste une doc... |
| Commentaire de Julien Sananikone [ 22/oct./07 17:42 ] |
|
type video : 244285 produits type Vidéo en pré-commande : 966 produits |
| Commentaire de Julien Sananikone [ 26/oct./07 16:16 ] |
| voila pour les vhs |
| Commentaire de Julien Sananikone [ 30/oct./07 16:22 ] |
| le comptage est biaisé car on est en train de faire l'import de notre nouveau référentiel DVDZ2/Bluray/HDDvd : mais les pourcentages ne peuvent que s'améliorer |
| Commentaire de Julien Sananikone [ 05/nov./07 15:53 ] |
|
les comptages faits en integ après l'intégration de la base
complète dvd-fr et de l'enrichissement des produits non dvd-fr
confirment bien les premiers comptages l'enrichissement sur la prod n'a pas encore été fait mais on devrait retomber sur les mêmes bases que l'integ puisqu'on opère le même enrichissement. |
| Commentaire de Julien Sananikone [ 05/nov./07 15:54 ] |
|
les comptages donnent lieu à l'établissement des filtres |
[APP-20908] [COSAV] Conditionner les macros "remboursement" selon si panier 1euro.com ou non Création: 19/juin/08 17:44 Mise à jour: 07/janv./09 15:46 Résolue: 05/déc./08 15:10 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Back-Office |
| Affecte la/les version(s): | 31.0.0 (TX-C) |
| Version(s) corrigée(s): | 38.0.0 (TX-D Bis) |
| Type: | Amélioration | Priorité: | Critique |
| Rapporteur: | Cedric Favero | Attribution: | Geneviève Beaujard |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
screenshot-1.jpg
screenshot-2.jpg
|
||||||||||||||||
| Liens des demandes: |
|
||||||||||||||||
| Pays: |
FRA - France
|
||||||||||||||||
| Projets PM: | *** RESERVE *** | ||||||||||||||||
| Classif1: | BO | ||||||||||||||||
| Classif2: | macros | ||||||||||||||||
| Description |
|
Lorsque la transaction a été effectuée avec un paiement
1euro.com et qu'une réclamation amène un remboursement , nous ne devons
jamais effectuer de remboursement porte-monnaie mais suivre une
procédure particulière pour transmettre les demandes de remboursement à
COFIDIS/1EURO. Il faudrait donc sur la fiche article que les macros "remboursement PMV" n'apparaissent pas lorsqu'il s'agit d'un panier 1euro.com et idéalement qu'à la place apparaissent une macro "remboursement 1euro.com" (qui ne ferait qu'envoyer le mail correspondant,le reste de la procédure étant manuelle). Dans le cas où il ne serait pas possible de conditionner l'apparation de telle ou telle macro en fonction du mode paiement utilisé, il nous faudrait au moins une alerte (popup) lorsqu'on tente de faire un remboursement PMV alors que le panier est 1euro.com. |
| Commentaires |
| Commentaire de Emeric Teil [ 13/oct./08 17:44 ] |
| Traîté en TX-C ? |
| Commentaire de Cedric Favero [ 13/oct./08 17:49 ] |
|
Oui mais pas correctement : - ne doit apparaitre QUE si panier payé par 1euro - doit envoyer un mail et ne le fait pas. Je refais un JIRA ou on garde celui-ci? |
| Commentaire de Cedric Favero [ 20/oct./08 15:31 ] |
|
Désolé pour le doublon , j'avais oublié ce JIRA. Ma demande est toutefois plus claire dans le JIRA |
| Commentaire de Cedric Favero [ 03/déc./08 10:02 ] |
| 2 captures pour illuster le pb |
| Commentaire de Cedric Favero [ 03/déc./08 15:41 ] |
| Je n'ai meme pas les droits pour passer mon JIRA en critique ( c'est une conspiration) |
| Commentaire de Geneviève Beaujard [ 05/déc./08 15:10 ] |
|
bzr ci source/src/com/babelstore/purchase/back/ItemView.jsp Committing to: bzr://perrier/dev/pole/tx/ modified source/src/com/babelstore/purchase/back/ItemView.jsp Committed revision 24741. Cedric tu peux tester le résultat sur mon serveur: item avec 1euro: http://bo.pm.boulard:2080/purchase_back?action=itemview&itemid=76245851 item sans: http://bo.pm.boulard:2080/purchase_back?action=itemview&itemid=78410228 |
| Commentaire de Cedric Favero [ 05/déc./08 18:03 ] |
|
Je ne saurais exprimer suffisamment la reconnaissance du SAV
(des petits trucs semblant betes peuvent parfois etre tres penibles) Par ailleurs j'insiste à nouveau sur la lourdeur que peuvent avoir parfois les process pour traiter des demandes finalement pas si complexes.. Il faut escalader des montagnes pour que puissent etre etudiées nos demandes! Et je ne dis pas çà d'un aspect négatif mais plutot pour relever ce qu'il y a à améliorer. Merci à tous et specialement à Genevieve :-) |
| Commentaire de Christophe Garcia [ 07/janv./09 15:12 ] |
| Cédric, que faites-vous quand le paiement s'est fait en partie via PMV et en partie via 1euro ? |
| Commentaire de Claire Durand [ 07/janv./09 15:17 ] |
|
pour la partie payée par pmv, on recrédite le pmv avec la cause "remboursement 1¿" la partie payée via 1¿ est remboursée par le biais de sips par moi-même claire |
| Commentaire de Christophe Garcia [ 07/janv./09 15:46 ] |
| OK Merci |
[APP-19035] Affichage chiffres tableaux de bord - Chiffres anormalement bas sur les catégories Mobilier, Décoration, Mode, Matériel de Sport Création: 19/déc./07 10:06 Mise à jour: 14/janv./08 12:42 Résolue: 02/janv./08 18:22 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 18.1.0 |
| Version(s) corrigée(s): | 18.1.3 |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Stéphanie Vignali | Attribution: | Patrick Pereira |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Site: | Prod | ||||||||
| Projets PM archivés: | Maintenance 18.x.x | ||||||||
| Description |
|
En regardant les chiffres ce matin on a eu la très mauvbaise
surprise de voir qu'ils étaient anormalement bas sur certaines
catégories comme le mobilier, la déco, la mode sans parler du Matériel
de Sport où il n'y a eu aucune vente ce qui n'est jamais arrivé depuis
l'ouverture du rayon. Pour exemples : CA Mode : 2667 ¿ le 17/12 et 137 ¿ le 18/12 CA Mobilier : 3015 ¿ le 17/12 ¿ et 132 ¿ le 18/12 CA Matériel de Sport : 3375 ¿ le 17/12 et 0 ¿ le 18/12 CA Chaussures : 2183 ¿ le 17/12 et 192 ¿ le 18/12 C'est spécifique à nos catégories car les chiffres de scatgéories culturelles et high tech n'ont pas l'air impacté par cette énorme différence de chiffre d'affaire. |
| Commentaires |
| Commentaire de Emmanuelle Lachamp [ 19/déc./07 10:23 ] |
|
Precision : les paniers ont l'air de disparaitre à vers 2 heures du mat les categories concernees sont : vetement mobilier decoration materiel de sport chaussures vin gastronomie Accessoires cycle et cyclomoteur Accessoires animalerie Cosmétiques 2 Roues linge de maison loisirs creatif plante sac et bagagerie |
| Commentaire de Patrice Boulanger [ 19/déc./07 10:32 ] |
|
Pouvez-vous m'indiquer ou et quand les informations de ce
type sont calculées (en temps réel, par un batch, ça utilise FAST et/ou
Oracle ?). De plus, on a eu des alertes cette nuit à 00h30 sur presque
tous les serveurs, est-ce que ça pourrait avoir un rapport ? Le retard
du connecteur Fast pourrait-il avoir un impact sur ces informations ? Merci. |
| Commentaire de Emmanuelle Lachamp [ 19/déc./07 10:50 ] |
|
C'est à nous que tu demandes ca ?? parce que là je crois que on n'en sait fichtre rien, nous ne sommes que de simples commerciaux |
| Commentaire de Stéphanie Vignali [ 20/déc./07 09:28 ] |
|
Est ce quelqu'un peut regarder ec qui se passe car le problème persiste aujourd'hui. C'est bloquant pour une équipe commerciale de ne pas avoir le CA de ses catégories. |
| Commentaire de Patrick Pereira [ 20/déc./07 18:49 ] |
|
Si je regarde en base : ----depuis ce matin (20/12) Nombre d'article de type vêtement mis en panier : 1 select count(*) from item where prd_type_code = 1480 and creation_date > to_date('19/12/2007','DD/MM/YYYY') and creation_date < to_date('21/12/2007','DD/MM/YYYY'); COUNT(*) ---------- 1 Nombre darticle de type vêtement en panier authorisé : 1 SELECT COUNT(distinct item_id) AS authorized_count FROM purchase, item WHERE item.purchase_id = purchase.purchase_id AND purchase.authorization_date > to_date('19/12/2007','DD/MM/YYYY') AND purchase.authorization_date < to_date('21/12/2007','DD/MM/YYYY') AND item.itm_status_code <> 50 AND prd_type_code = 1480; AUTHORIZED_COUNT ---------------- 1 ----journée du 19 Nombre d'article de type vêtement mis en panier : 47 Nombre darticle de type vêtement en panier authorisé : 7 ----journée du 18 Nombre d'article de type vêtement mis en panier : 1299 Nombre darticle de type vêtement en panier authorisé : 257 ----journée du 17 Nombre d'article de type vêtement mis en panier : 2615 Nombre darticle de type vêtement en panier authorisé : 577 ----journée du 16 Nombre d'article de type vêtement mis en panier : 2544 Nombre darticle de type vêtement en panier authorisé : 547 Il y a en effet une très forte baisse à partir du 19 mais qui ne correspond pas aux chiffres du tableau de bord. Je vais vérifier la méthode de calcul. |
| Commentaire de Patrick Pereira [ 21/déc./07 11:43 ] |
|
Le problème vient d'un changement de comportement de
l'application qui depuis la V18_1 (le 18/12 à 5h00) stocke le
prd_type_code du produit complément à la place du prd_type_code du
produit de base. Dans le vue agrégée (itm_period_summary) on a du coup : Le 17/12 : AUTHORIZED_COUNT AUTHORIZED_COST_PRICE_SUM PRD_TYPE_CODE ---------------- ------------------------- ------------- 252 6267.66 1480 Le 18/12: AUTHORIZED_COUNT AUTHORIZED_COST_PRICE_SUM PRD_TYPE_CODE ---------------- ------------------------- ------------- 6 173.5 1480 264 5719.19 1481 Le 19/12: AUTHORIZED_COUNT AUTHORIZED_COST_PRICE_SUM PRD_TYPE_CODE ---------------- ------------------------- ------------- 180 3695.21 1481 Dans la table item on voit que les item prennent le prd_type_code du produit complément : -------------------------- Pour la journée du 16 : select count(*), prd_type_code from item where prd_type_code in( 1480,1481) and creation_date > to_date('15/12/2007','DD/MM/YYYY') and creation_date < to_date('17/12/2007','DD/MM/YYYY') group by prd_type_code; COUNT(*) PRD_TYPE_CODE ---------- ------------- 2544 1480 Le 17 : COUNT(*) PRD_TYPE_CODE ---------- ------------- 2615 1480 Le 18 : COUNT(*) PRD_TYPE_CODE ---------- ------------- 1299 1480 1158 1481 Le 19 : COUNT(*) PRD_TYPE_CODE ---------- ------------- 47 1480 2245 1481 Le 20 : COUNT(*) PRD_TYPE_CODE ---------- ------------- 1 1480 1834 1481 Alors que dans la table advert on a toujours le prd_type_code du produit de base. Ex pour le 20 : select count(*), prd_type_code from advert where advert_id in ( select advert_id from item where prd_type_code = 1481 and creation_date > to_date('19/12/2007','DD/MM/YYYY') and creation_date < to_date('21/12/2007','DD/MM/YYYY') ) group by prd_type_code; COUNT(*) PRD_TYPE_CODE ---------- ------------- 1535 1480 => dans le tableau de bord il faut tenir compte des produits compléments ou => ne mettre que les prd_type_code des produits de bases dans le item. |
| Commentaire de Christophe Garcia [ 21/déc./07 11:45 ] |
|
Modifier affichage BO en agrégeant PRD et PRD_CPLT ou Revenir à un stockage du PRD et pas du PRD_CPLT |
| Commentaire de Arnaud Forgues [ 26/déc./07 10:45 ] |
|
La correction est mise en place au niveau applicatif : plus
qu'à attendre le déploiement de la V18.1.3 pour que le problème soit
rétabli. En ce qui concerne la correction des données érronées depuis la V18.1 (mardi 18 décembre), 2 scripts sont prêts dans le répertoire V:\Database\V18.1.3\integ. Par contre on préferera attendre le retour de Patrick (le 2 janvier prochain) pour passer ces scripts en PROD. ------------------------- CVS: ---------------------------------------------------------------------- CVS: Enter Log. Lines beginning with `CVS:' are removed automatically CVS: CVS: Committing in . CVS: CVS: Modified Files: CVS: Tag: BRANCH_V18 CVS: src/com/babelstore/purchase/business/ItemBusinessBean.java CVS: ---------------------------------------------------------------------- |
| Commentaire de Arnaud Forgues [ 28/déc./07 11:13 ] |
|
La V18.1.3 a été mis en PROD ce matin ! Les chiffres devraient donc revenir partiellement demain (tout sauf ce qui a été vendu avant 5h du matin) et totalement après demain :D Pour les chiffres depuis le 18/12 jusqu'à aujourd'hui, Patrick et moi passeront des scripts la semaine prochaine afin de les récupérer, cependant il ne s'agit que de données informatives et il vaut mieux se baser sur du reporting BI pour avoir de vrais chiffres métier quoi qu'il arrive ;-) Voilou, Arnaud |
| Commentaire de Arnaud Forgues [ 28/déc./07 11:14 ] |
| je le réouvre juste pour penser aux scripts ! |
| Commentaire de Christophe Garcia [ 02/janv./08 10:24 ] |
| Ils en sont où ces scripts ? |
| Commentaire de Stéphanie Vignali [ 02/janv./08 10:31 ] |
| On les attends avec impatience ! |
| Commentaire de Patrick Pereira [ 02/janv./08 18:22 ] |
|
Les scripts sont passés. Vous pouvez retrouver les véritables chiffres sur les tableaux de bord. |
[APP-20915] Tracking Question et Souhait Création: 20/juin/08 10:02 Mise à jour: 07/sept./09 12:17 Résolue: 07/sept./09 11:56 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Tracking |
| Affecte la/les version(s): | 23.0.3 |
| Version(s) corrigée(s): | 52.0.0 (CTN-M) |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Charles Decaux | Attribution: | Renaud Dierickx |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ESP - Espagne
|
| Site: | Prod |
| Projets PM: | *** CHASSE *** |
| Classif1: | PROMO |
| Classif2: | chasse |
| Description |
|
Hello, je pense que le tracking question et le tracking souhait ne sont pas correctement implémentés en Espagne.: aucune remontée sur ces trackings en terme de visites et en terme d'achats. Par ailleurs, dans le BO on ne retrouve aucune trace de ces trackings. Peut-on faire une passe dessus pour voir comment le mettre en place correctement ? Merci |
| Commentaires |
| Commentaire de Swan Desportes [ 24/juin/08 09:54 ] |
| A faire en JIRA hebdo |
| Commentaire de Clement Balay [ 22/juil./08 14:57 ] |
|
Est-ce que l'on pourrait avoir plus de précisions sur les liens mis en cause. Par exemple une capture d'écran du lien en question ou le nom du lien et la page sur laquelle il est. merci |
| Commentaire de Fabrice Feugas [ 20/janv./09 13:42 ] |
| Pas de nouvelles de ce JIRA depuis juillet. Peut-on considérer que c'est ok? |
| Commentaire de Charles Decaux [ 20/janv./09 15:31 ] |
|
Hello ! Non malheureusement ce n'est pas corrigé. Que ce soit dans Xiti ou dans BI, je n'ai aucune donnée (pas de visite, pas de panier) liée aux trackings QUESTION ou SOUHAIT. Les liens mis en cause sont : - le mailing souhait qui part quand un souhait se réalise - concernant la question, je ne connais pas la procédure d'allocation du tracking. Est-ce qu'il se retrouve avec un tracking question dès lors qu'il en pose une ? Ou bien existe-t-il un lien spécifique qui doit être tracké ? Je pense qu'il faudrait jeter un coup d'oeil aux spécifications et à ce qu'on constate sur la France pour répliquer le même schéma sur l'Espagne. Merci |
| Commentaire de Renaud Dierickx [ 04/sept./09 17:10 ] |
|
C'est parce que les tracking n'existent pas ! >>>> Pour les souhaits, le code de tracking est : 30 Existe sur : >> FR : http://bo.priceminister.com/tracking_back?action=trackingsearch&name=&usr_tracking_id=30&start_date=&end_date=&number_rows=100&x=51&y=15 >> UK : http://bo.priceminister.co.uk/tracking_back?action=trackingsearch&name=&usr_tracking_id=30&start_date=&end_date=&number_rows=100&x=12&y=5 N'existe pas sur >> ES : http://bo.priceminister.es/tracking_back?action=trackingsearch&name=&usr_tracking_id=30&start_date=&end_date=&number_rows=100&x=15&y=11 >>>> Pour les questions, le code de tracking est : 40 Existe sur : >> FR : http://bo.priceminister.com/tracking_back?action=trackingsearch&name=&usr_tracking_id=40&start_date=&end_date=&number_rows=100&x=51&y=15 >> UK : http://bo.priceminister.co.uk/tracking_back?action=trackingsearch&name=&usr_tracking_id=40&start_date=&end_date=&number_rows=100&x=12&y=5 N'existe pas sur >> ES : http://bo.priceminister.es/tracking_back?action=trackingsearch&name=&usr_tracking_id=40&start_date=&end_date=&number_rows=100&x=15&y=11 ====================> JE VAIS LES CREER PAR SCRIPT ! |
| Commentaire de Renaud Dierickx [ 04/sept./09 17:58 ] |
| [CAJ2009Q3CTN] |
| Commentaire de M'hand Hadjoudj [ 07/sept./09 11:52 ] |
| Ils sont où les scripts ? (ne pas répondre DTC) |
| Commentaire de Renaud Dierickx [ 07/sept./09 11:56 ] |
|
Dans le répertoire où il y a les scripts de la V52_0_0... V:\Database\V52_0_0\integ\01_PREPARE\ONLINE\done |
| Commentaire de M'hand Hadjoudj [ 07/sept./09 12:08 ] |
|
OK merci. Pour info, les noms des scripts doivent comporter le numéro du JIRA. |
[BIN-453] [Jeu permanent vendeur] : Rapport ventilation nb de vendeur par nb de vente Création: 02/juin/08 16:01 Mise à jour: 17/sept./08 12:30 Résolue: 17/juil./08 11:21 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | CRM |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Charlotte Fachan | Attribution: | Julien Girardet |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Individual seller distribution by item count.xls
|
| Pays: |
FRA - France
|
| Description |
|
Bonjour, dans le cadre de la mise en place de notre jeu concours permanent vendeur, nous aurions besoin de définir des catégories de vendeur (gros, moyen, petit). Serait -il possible d'avoir un rapport sur le modele du rapport Buyers distribution by purchase count mais orienté vente. A votre dispo pour s'en parler. Merci Charlotte |
| Commentaires |
| Commentaire de Florian Ambrosi [ 09/juin/08 17:31 ] |
|
Le rapport "Individual seller distribution by item count"
est passé en prod en France et en Espagne dans le dossier "Item". Florian. |
| Commentaire de Charlotte Fachan [ 16/juin/08 16:55 ] |
|
Merci pour ce rapport. Petite précision : cela concerne que les vendeurs part ? on parle bien en nombre de vente ou en nombre d'annonce ? Merci de ton retour. Bonne journée Charlotte |
| Commentaire de Florian Ambrosi [ 16/juin/08 17:03 ] |
|
Charlotte, Le rapport concerne les vendeurs particuliers et il s'agit du nombre de vente. Florian. |
| Commentaire de Charlotte Fachan [ 16/juin/08 17:08 ] |
|
Super ! merci Florian |
| Commentaire de Charlotte Fachan [ 30/juin/08 19:49 ] |
|
Bonjour Romain, comme convenu ensemble, pourrais tu me transmettre ce rapport avec tout l'historique vente / vendeurs depuis le début de PriceMinister. Merci beaucoup Charlotte |
| Commentaire de Charlotte Fachan [ 16/juil./08 17:02 ] |
|
Romain, comme convenu pourrais tu me transmettre ce rapport. J'en ai vraiment besoin afin de définir les différentes catégories de vendeur et les intégrer dans le réglement final (qui n'attend plus que cette donnée pour être intégré ds infoglue) Merci Charlotte |
| Commentaire de Romain Czornomaz [ 16/juil./08 17:46 ] |
|
Julien, Avant de démarrer les dev sur le rapport de tirage au sort, il faut fournir les données de segmentation. Peux tu t'en occuper? Romain |
| Commentaire de Julien Girardet [ 17/juil./08 11:19 ] |
| Resultat du rapport "Individual seller distribution by item count " (ITEM) pour tout l'historique de PriceMinister |
| Commentaire de Julien Girardet [ 17/juil./08 11:21 ] |
|
Bonjour Charlotte, tu trouveras en piece jointe du JIRA le fichier excel du resultat du rapport "Individual seller distribution by item count " pour tout l'historique de Price. Julien |
| Commentaire de Charlotte Fachan [ 18/juil./08 18:04 ] |
|
Merci julien, je regarde asap et vous tiens informé Charlotte |
| Commentaire de Agathe Remy [ 17/sept./08 12:30 ] |
|
Suite au point hebdo BI, il semble que le tirage au sort se soit bien passé. Je clôture donc ce JIRA. Agathe |
[BIN-312] [TFV] : Rapport géolocalisation des vendeurs recrutés Création: 02/avr./07 14:59 Mise à jour: 14/sept./07 18:03 Résolue: 04/mai/07 15:10 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | CRM |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Thomas Beylot | Attribution: | Romain Czornomaz |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Hello, Jira dont j'ai déjà parlé avec Romain. L'idée est de construire un rapport qui me donne le nombre de nouveaux vendeurs recrutés sur une période en fonction des départements. En effet, suite à l'OP la poste nous aimerions savoir si celle-ci a poussé le recrutement de vendeurs dans les départements concernés. Ainsi, j'ai construit un rapport tout seul comme un grand que j'ai donc soumis à Romain car les résultats me semblaient bizarres (par exemple sur la semaine du 19 au 25 mars il me sort 1 211 nouveaux vendeurs alors que par exemple le mois dernier on en avait recruté 12 906...). Le rapport est dispo dans mes favoris sous un nom compréhensible (géoloc etc). Pouvez-vous regardé ça et me dire ce qu'il en est ? A titre indicatif j'ai le nb de nouveaux vendeurs recrutés par mois (et pas par période, malheureusement): - 16 962 en janvier - 12 906 en février datas qui proviennent des rapports titan. merci !! thomas. |
| Commentaires |
| Commentaire de Thomas Beylot [ 04/avr./07 11:35 ] |
|
hello, suite à un petit travail sur Bo avec Romain, on se rend compte que cette demande mériterait de passer en "mode projet"... en effet on obtient des chiffres qui ne sont pas en adéquation avec ceux de François et donc il faut qu'on mène l'enquete. A prioriser dans la liste des demandes... merci ! thomas. |
| Commentaire de Romain Czornomaz [ 27/avr./07 14:05 ] |
|
Salut Thomas, Le rapport sur la géolocalisation des nouveux vendeurs est en prod sur la plateforme BI dans le repertoire suivant: France/Seller/Priceminister - Sellers geolocalization Peux tu le valider et fermer le JIRA ensuite :) Merci d'avance, Romain |
| Commentaire de Romain Czornomaz [ 04/mai/07 15:10 ] |
|
Thomas, Je passe la demande en resolu. si tu as un problème lié au rapport, n'hésites pas à la réouvrir. :) Romain |
| Commentaire de Thomas Beylot [ 22/mai/07 18:54 ] |
|
yo juste je me permets de réouvrir le pti jira pour savoir si tu avais reçu mon magnifique mail pour vérifier 2/3 trucs sur le rapport... |
[EXP-4149] installation modules PERL sur Pommery : DBI (avec driver Oracle) + AppConfig Création: 31/déc./07 10:52 Mise à jour: 25/janv./08 11:42 Résolue: 25/janv./08 11:42 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Samir Beghdadi | Attribution: | Julien Girardet |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
salut, pourrais tu m'installer les modules PERL sur Pommery : DBI (avec driver Oracle) + AppConfig merci d'avance julien GIRARDET julien.girardet@priceminister.com |
| Commentaires |
| Commentaire de Jérémie Bennejean [ 31/déc./07 11:45 ] |
|
Le module DBI est installé sur pommery. test ok idem pour AppConfig |
| Commentaire de Jérémie Bennejean [ 31/déc./07 11:46 ] |
| Merci de m'indiquer si tout est fonctionnel de votre coté. |
| Commentaire de Samir Beghdadi [ 31/déc./07 14:02 ] |
|
merci pour DBI + AppConfig peux tu également installer le driver DBD::Oracle ainsi que le module MIME::Lite merci d'avance Julien. |
| Commentaire de Jérémie Bennejean [ 31/déc./07 16:22 ] |
|
Installé. Pouvez-vous vérifier de votre coté? Merci |
| Commentaire de Jérémie Bennejean [ 04/janv./08 10:20 ] |
| N'ayant pas de réponses je résouds. |
| Commentaire de Julien Girardet [ 04/janv./08 14:39 ] |
|
Le module MIME::Lite est bien installé sur Pommery,
cependant pour fonctionner correctement j'ai besoin du module
Email::Date::Format Donc peux tu m'installer le module Email::Date::Format sur Pommery ? Désolé des demandes successives d'installation de module, mais je découvre au fur à mesure les modules dont j'ai besoin. merci |
| Commentaire de Jérémie Bennejean [ 04/janv./08 15:51 ] |
| C'est installé |
| Commentaire de Julien Girardet [ 04/janv./08 16:16 ] |
|
voici le message d'erreur que j'obtiens : Use of uninitialized value in substitution (s///) at /usr/lib/perl5/site_perl/5.8.5/MIME/Lite.pm line 511. Use of uninitialized value in scalar assignment at /usr/lib/perl5/site_perl/5.8.5/MIME/Lite.pm line 513. Use of uninitialized value in pattern match (m//) at /usr/lib/perl5/site_perl/5.8.5/MIME/Lite.pm line 514. apparement des valeurs du module MIME::Lite ne sont pas initialisées... |
| Commentaire de Jérémie Bennejean [ 04/janv./08 16:20 ] |
|
J'ai réinstallé avec une autre méthode. L'installation est ok. |
| Commentaire de Julien Girardet [ 04/janv./08 16:58 ] |
|
j'ai toujours le meme message d'erreur : Use of uninitialized value in substitution (s///) at /usr/lib/perl5/site_perl/5.8.5/MIME/Lite.pm line 511. Use of uninitialized value in scalar assignment at /usr/lib/perl5/site_perl/5.8.5/MIME/Lite.pm line 513. Use of uninitialized value in pattern match (m//) at /usr/lib/perl5/site_perl/5.8.5/MIME/Lite.pm line 514. |
| Commentaire de Jérémie Bennejean [ 07/janv./08 11:06 ] |
|
Salut, Le script suivant fonctionne: #!/usr/bin/perl -w # Created test_email.pl the 13:29:09 (31/10/2006) on hercule # # # Application Priceminister # email: exploitation@priceminister.com # Documentation: # http://wikiexploit/ use lib '/data/mrtg/perl'; use strict; use MIME::Lite; my $subject = 'Essai on Hercule'; my $mailmsg = "Essai de mail\n"; my $msg = MIME::Lite->new( From => 'pmas@priceminister.com', To => 'hostmaster@priceminister.com', Subject => 'report on Hercule', Type => 'TEXT', Data => $mailmsg, ); # $msg->attach( # Type => 'x-gzip', # Path => "ess.txt", # ); # ftpCompute is still on beta test so, we mail $msg->send; #$(uencode ess.txt | sendmail -t "eric.vannier@priceminister.com <mailto:eric.vannier@priceminister.com>") Je pense que MIME est bien installé, cela doit venir de ton script. Merci |
| Commentaire de Julien Girardet [ 07/janv./08 11:41 ] |
|
salut, J'ai testé également de mon coté, le module MIME fonctionne. l'erreur provenait bien de mon script, il manquait en début de script : use lib '/data/mrtg/perl'; Merci. |
| Commentaire de Jérémie Bennejean [ 07/janv./08 12:14 ] |
|
Je ferme le jira alors. |
| Commentaire de Julien Girardet [ 10/janv./08 17:41 ] |
|
Salut, Dans le cadre d'une future mise en PROD du projet SANITY CHECK BI Je souhaiterais que les modules PERL installés sur Pommery le soit également sur LATONE Peux tu faire le necessaire aupres de JET. Pour rappel, les modules PERL necessaires : DBI DBD::Oracle AppConfig MIME::Lite Email::Date::Format Merci |
| Commentaire de Patrice Boulanger [ 10/janv./08 18:00 ] |
|
Vous avez les accès nécessaires auprès de Jet pour créer les
MAI (voir avec Agathe si nécessaire), il n'y a pas nécessité de passer
par nous pour cela, ça fera des interlocuteurs supplémentaires pour
rien. Patrice. |
| Commentaire de Julien Girardet [ 11/janv./08 12:15 ] |
|
A l'intention d'Agathe : Apres avoir verifié les modules PERL installés sur LATONE, voici les modules manquant qui feront l'objet d'une demande d'installation aupres de JET : - Module MIME::Lite - Module AppConfig - Module Email::Date::format les modules DBI et DBD::ORACLE sont deja installés sur LATONE |
| Commentaire de Agathe Remy [ 15/janv./08 18:37 ] |
|
15/01/2008 15:09 JMH Ajout des modules suivants en prérequis de MIME::lite : Mail::Address MIME::Types File::Basename MIME::Base64 MIME::QuotedPrint 15/01/2008 15:51 JMH Modules effectivement installés :: TimeDate-1.16 Pod-Escapes-1.04 Pod-Simple-3.05 Test-Simple-0.74 Test-Pod-1.26 MailTools-2.02 MIME-Base64-3.07 ( gcc ) MIME-Types-1.23 Email-Date-Format-1.002 MIME-Lite-3.021 AppConfig-1.66 15/01/2008 15:53 JMH Cela correspond-t-il à la demande ? |
| Commentaire de Julien Girardet [ 16/janv./08 10:55 ] |
|
Les modules sont bien installés sur Latone et fonctionnent Merci. |
[BIN-415] Opt-in partenaires Espagne Création: 18/févr./08 14:55 Mise à jour: 18/févr./08 15:09 Résolue: 18/févr./08 15:09 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Charles Decaux | Attribution: | Agathe Remy |
| Résolution: | Invalid | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ESP - Espagne
|
| Description |
|
La fonctionnalité opt-in partenaires est désormais active sur l'Espagne. Avant que cette fonctionnalité ne soit active, nous avons inséré de nombreux contacts grâce aux différentes opérations que nous avons menées. Certains de ces contacts étaient opt-in partenaires. Il faudrait donc mettre à jour l'intégration de ces contacts en prenant en compte leur statut "opt-in partenaires". Merci |
| Commentaires |
| Commentaire de Agathe Remy [ 18/févr./08 15:09 ] |
|
Charles, Le BI ne modifie jamais les données du site. Il faut que tu vois cela avec l'équipe d'exploitation : Patrick ou Eric qui s'occupe de l'intégration des contacts des jeux concours?! Agathe |
[APP-18727] [CoSAV] Filtrer les paniers en observation Création: 27/nov./07 16:46 Mise à jour: 27/nov./09 12:14 |
|
| Etat: | Ré-ouvert |
| Projet: | Application PriceMinister |
| Composants: | Back-Office |
| Affecte la/les version(s): | 17.2.1 |
| Version(s) corrigée(s): | Aucune |
| Type: | Nouvelle fonctionnalité | Priorité: | Mineur |
| Rapporteur: | Sebastien Bruzzone | Attribution: | Dispatcher (Pôle TX) |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Projets PM: | *** STANDBY *** |
| Classif1: | PANIER |
| Classif FONC: | CoSAV |
| Description |
|
Bonjour, Nous aimerions pouvoir trier les paniers en observation. http://bo.priceminister.com/purchase_back?action=purchasesearch&fuzzy=false&numberrows=200&order=1&pchstatuscode=120 et http://bo.priceminister.es/purchase_back?action=purchasesearch&fuzzy=false&numberrows=200&order=1&pchstatuscode=120 En effet nous sommes actuellement dans une période de forte croissance où nous devons traiter 600 paniers le lundi matin avec aucun tri possible. A ce jour, les paniers en obs sont uniquement triés par ordre chonologique, nous aimerions pouvoir avoir des tris par type, cb (montant), 1¿ , PMV, cpn, date Avoir des filtres permettrait à l'équipe de pouvoir traiter plus efficacement les paniers en se repartissant le travail sur des jours, les montants ou les types de panier. |
| Commentaires |
| Commentaire de Agathe Remy [ 27/nov./07 19:38 ] |
|
Sébastien, Ce n'est pas l'équipe BI qui s'occupe du BackOffice (http://bo.priceminister.com). Nous ne gérons que le portail BI (http://bi.priceminister.com). Je déplace donc ta demande dans le projet Application géré par l'équipe Etude&Dévéloppement. Cordialement, Agathe |
| Commentaire de Emeric Teil [ 07/févr./08 14:10 ] |
| A prendre en compte dans les demandes de type CoSAV. |
| Commentaire de Cedric Favero [ 03/févr./09 18:22 ] |
|
Sebastien , peux tu faire un document regroupant tes
demandes d'amélioration pour la page de paniers en observations: - Options de tris nécessaires - Données supplémentaires à faire figurer (ex: mode de paiement, mode d'expédition, etc..) - Options d'affichage eventuellement (certaines données à faire ressortir?) On le verra ensemble et on le joindra à ce JIRA. Merci. |
| Commentaire de Emeric Teil [ 04/nov./09 18:04 ] |
| Passe dans notre backlog... |
| Commentaire de Christophe Garcia [ 05/nov./09 18:30 ] |
| MDPLVC |
| Commentaire de Christophe Garcia [ 27/nov./09 12:00 ] |
|
Je réouvre en attendant que l'on trouve la bonne marche à suivre pour ces types de demandes. A traiter en backlog ? A traiter dans JIRA ? Comments ces projets reviennent-ils sur la table s'ils sont traités en backlog ? Création de nouveaux JIRA ? |
[APP-20567] [UK] Mise en place de la page alpha Création: 20/mai/08 10:35 Mise à jour: 15/juil./08 15:44 Résolue: 04/juil./08 17:04 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 25.0.0 (CTN-D) |
| Version(s) corrigée(s): | 25.0.0 (CTN-D) |
| Type: | Nouvelle fonctionnalité | Priorité: | Majeur |
| Rapporteur: | Swan Desportes | Attribution: | Rémi Virlouvet |
| Résolution: | Corrigé | ||
| Σ Estimation restante: | Non spécifié | Estimation restante: | Non spécifié |
| Σ Temps consacré: | Non spécifié | Temps consacré: | Non spécifié |
| Σ Estimation originale: | Non spécifié | Estimation originale: | Non spécifié |
| Pièces jointes: |
Brief page alpha.doc
|
||||||||||
| Sous-tâches: |
|
||||||||||
| Pays: |
GBR - Royaume Uni
|
||||||||||
| Projets PM: | *** RESERVE *** |
| Description |
|
Mise en place de la page beta avec formulaire d'inscription (cf. inscription NL de la HP) : voir brief de CDE.
|
| Commentaires |
| Commentaire de Charles Decaux [ 20/mai/08 16:46 ] |
|
Voici le brief, pas validé par les chefs, mais à priori ils ne feront que des modifs de texte. N'hésitez pas si vous avez besoin d'aide. Je n'ai pas donné d'orientation graphique, mais je pense que le mieux c'est de faire du PriceMinister. Merci |
| Commentaire de Charles Decaux [ 21/mai/08 18:46 ] |
|
Voici les commentaires des caïds sur ce brief : - se laisser la possibilité de modifier la page afin de motiver l'inscription par un jeu concours... - priviliégier graphiquement le formulaire d'inscription aux liens vers PM FR et PM ES Sinon c'est good ! Merci |
| Commentaire de Clement Balay [ 22/mai/08 16:19 ] |
|
Ça y est, j'ai mis en place le prototype de la page alpha
qui est disponible à cette adresse: /info/alpha, Le contenu peut être
modifié dans ce contenu: /default/Article/Main Article/AlphaPage. Pour modifier certains wordings spécifique UK, il faut modifier les labels en version UK ici: /default/Labels/_Mon Compte/NewsletterPopup/* |
| Commentaire de Clement Balay [ 22/mai/08 16:21 ] |
| Les labels spécifique à mettre dans les labels sont indiqués dans le brief qui en pièce jointe du jira |
| Commentaire de Clement Balay [ 22/mai/08 16:26 ] |
|
mes publications: CMS1 - default - ALPHA_PAGE CMS1 - default - AlphaPage |
| Commentaire de Charles Decaux [ 02/juin/08 12:20 ] |
|
Hello, la pop up qui s'ouvre quand on clique sur le bouton GO est en français. Il faudrait la mettre en anglais avec le texte prévu dans le brief à cet effet. Merci |
| Commentaire de Ariane Baldinger [ 02/juin/08 16:12 ] |
| page accessible ici : http://www.pm.bollinger:2680/info/alpha |
| Commentaire de Rémi Virlouvet [ 06/juin/08 11:45 ] |
|
pop up traduite. que reste t il exactement à faire? |
| Commentaire de Rémi Virlouvet [ 06/juin/08 11:51 ] |
|
page désormais accessible ici : http://bouk.priceminister.jmh/info/alpha |
| Commentaire de Charles Decaux [ 09/juin/08 10:27 ] |
|
Hello Rémi, En fait dans le brief que j'ai livré, il y avait plusieurs spécifications concernant la popup de confirmation : - si possible le faire par le biais d'une alerte javascript et non pas une popup - il faudrait que l'inscription soit immédiate et non pas en deux temps .Dans la pop up, quand on met son mail, il faut reconfirmer qu'on veut s'inscrire. Cette étape n'est pas nécessaire. Une fois que l'internaute a renseigné son mail et cliqué sur "Go" alors c'est bon, il est inscrit, il faut juste mettre un message de confirmation. En revanche il faudrait vérifier avec les dévs que c'est possible. - enfin la traduction de cette pop up avait déjà été livrée dans le brief. Evidemment cette traduction est valable seulement si on peut inscrire l'internaute immédiatement et ne pas attendre sa confirmation. Merci et à ta dispo pour en parler. Charles |
| Commentaire de Swan Desportes [ 09/juin/08 11:21 ] |
|
Hello Charles - pour le popup --> c'est du DEV. On garde le système actuel, sinon il faut faire un mini projet... - pour l'inscription immédiate : mais remarque que ci dessus. - il faut donc adapter le wording. On a décidé de faire simple et efficace parce que l'on n'a pas les moyens de faire autrement avec les délais actuels. D'autre part, on tient absolument à ce que FR, ES et UK soient identiques. Donc ce dev dépasserait le simple cadre de UK (à discuter en CoMarket). Merci et à ta dispo pour en parler. Swan |
| Commentaire de Charles Decaux [ 10/juin/08 09:35 ] |
| ok merci Swan, je vais en parler avec Odile afin qu'elle fasse éventuellement la demande de simplification de l'inscription lors du prochain comarket. |
| Commentaire de Charles Decaux [ 12/juin/08 19:05 ] |
|
Swan --> Big bug : quelque soit le mail que je mettre sur http://bouk.priceminister.jmh/info/alpha il me dit que je suis déjà inscrit. C'est peut-être un souci de connexion à la base... Je ne sais pas |
| Commentaire de Charles Decaux [ 12/juin/08 19:10 ] |
|
Rémi : peux-tu apporter les améliorations suivantes à la page : - javascriptage des liens (c'est sûrement côté Clément) - ajouter un texte à la fin de la page qui dit "Interested in PriceMinister ? Give us your opinion and help us out ! " Le lien à mettre sur ce texte http://vovici.com/wsb.dll/s/e27fg34d48 Si tu penses qu'il faut reformuler cette phrase n'hésite pas. Enfin, on va sûrement faire un jeu concours permanent pour les personnes qui s'inscrivent, il faudra peut être remplacer "please write down your email " par "please write down your email. If you are lucky, you might win £100 !". Et du coup il faudra peut être ajouter un lien en bas de la page vers le règlement du jeu concours. Merci |
| Commentaire de Charles Decaux [ 16/juin/08 19:07 ] |
|
Patrice, Swan, quand je clique sur une page qui ne devrait pas être accessible, j'arrive sur une page qui dit "Status: 503 Server Full Content-type: text/html Cache-Control: private " Serait-il possible de remédier à cela ? Il faudrait qu'on arrive sur la page alpha. Merci |
| Commentaire de Charles Decaux [ 25/juin/08 19:36 ] |
|
Rémi, est-ce que toutes les modifications demandées sont bien prêtes ? As-tu mis un lien vers le jeu concours ? Merci de ton retour |
| Commentaire de Rémi Virlouvet [ 26/juin/08 17:28 ] |
|
Swan, tout est ok sauf que quelque soit l'adresse renseignée, il indique que l'adresse existe déjà . Par ailleurs, le logo affiché est celui de la france, il faudrait mettre un logo sans base line et avec code barre merci et à ta dispo |
| Commentaire de Rémi Virlouvet [ 26/juin/08 17:43 ] |
| p.s. : le commentaire ci dessus est de Charles :) |
| Commentaire de Swan Desportes [ 27/juin/08 15:23 ] |
|
Pour le wording, tu as la main : tout est dans IG. Pour le fonctionnement de l'inscription, tu pourrais me faire un sous-jira. Merci. |
| Commentaire de Charles Decaux [ 27/juin/08 18:41 ] |
|
Il faudrait remplacer "It should be ready at the end of 2008." par "It will be opening soon" ou quelque chose du genre, sans préciser de date. merci. |
| Commentaire de Rémi Virlouvet [ 30/juin/08 12:19 ] |
| Done. |
mail de notification de deploiement reussi : je ne l'ai pas recu pour venus et pour rhome
(EXP-3645)
|
|
| Etat: | Ouvert |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | Jérémie Bennejean | Attribution: | Sébastien Raguet |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Description |
|
Il faut surveiller le fichier de conf /etc/postfix/main.cf Et voir si tous sont identiques. |
| Commentaires |
| Commentaire de Ange Ferrari [ 14/sept./07 16:28 ] |
|
Je veux bien mais je crois qu'il va falloir faire quelque chose :) amphitrite ec5284b40783ebb89c69607c6f760b55 /etc/postfix/main.cf amphore d038cc36ad95d0a1af1597c4a865b834 /etc/postfix/main.cf angita bb4b844699297f0b04af56500f981e3b /etc/postfix/main.cf aricia 4030683f1988c5a3b45f8c39ded098e6 /etc/postfix/main.cf aurore bc6aa751fec4e4f8c809319c097fe197 /etc/postfix/main.cf bacchus 860bd76cc2c95e86cedabe0148b3f7c9 /etc/postfix/main.cf critias 6899c03e333c556875d2e4cd376103cc /etc/postfix/main.cf cupidon fc393f1b0361076dcf3a9f59d57f4154 /etc/postfix/main.cf esculape 5b5885d133ec39dafbb90afb0d488f59 /etc/postfix/main.cf evandre 22b1b9443da551906e370b046c95305a /etc/postfix/main.cf graces02 c9c365590362df8cf2f9799bf1bf38dd /etc/postfix/main.cf hercule c46317d70af4d89cb83670130791a53e /etc/postfix/main.cf janus 71652f647c456bd958cbd53622e9306e /etc/postfix/main.cf junon ddab4788753d7c9db9d90ccae12b533e /etc/postfix/main.cf jupiter 1e4ad2d463edc8d2fb23b192640d95bc /etc/postfix/main.cf latone a6cd5fcb8e51fb3f2cffe7063ddb9290 /etc/postfix/main.cf lykeia 9adf02051da61835196e5fc6e1c10f31 /etc/postfix/main.cf mercure 138f7f88b7c24bccdc1b2050fc1c6ec5 /etc/postfix/main.cf neptune 4a44ce120bf191f24e0490847264b61c /etc/postfix/main.cf orcus 809bec1aa114b8a3fc1227f3c7c1b4c1 /etc/postfix/main.cf pallas 0a3d3bf1d72c0a98cb001d775ebdd563 /etc/postfix/main.cf parques fb2ae2d040caf9ad56f90c8d9dc82964 /etc/postfix/main.cf pelasgos 1b0a32c0a581398d9736566d549407b8 /etc/postfix/main.cf phaeton 82b17d237794079c3127aeeaeaaae1a8 /etc/postfix/main.cf rhome 20c485e462e3d11d20a178871ac87a7f /etc/postfix/main.cf salus 93d3c9a6b5e3db710d131015ed25ae74 /etc/postfix/main.cf saturne 81c4aadfb371a52464c14c2244014ee3 /etc/postfix/main.cf sol 69960a6a0baf6b2682ad45c5eacb6dce /etc/postfix/main.cf tellus a8b7293626af327da42a8b183c38971a /etc/postfix/main.cf terra fdd242191fb70b825942e79ca45bedca /etc/postfix/main.cf timee ed3bebca31f48add9d4a49035b507d9b /etc/postfix/main.cf titan 83dd4253cdb4d2deb496bcbbb66c7fb4 /etc/postfix/main.cf titeia b1bce9afa869227a4f95b3790830eb46 /etc/postfix/main.cf venus 85cc7c5f06acfa8912e9da79945eb923 /etc/postfix/main.cf |
| Commentaire de Jérémie Bennejean [ 06/nov./07 18:44 ] |
| Ok la surveillance du /etc/postfix par le biais d'un md5sum ne fonctionnera pas du fait que tous ces fichiers ne seront jamais identiques puisqu'il comporte le nom du host sur lequel ils sont. |
[BIN-429] [Sales] : Ajout de dimensions dans la base "FRANCE - ADVERT" (ean et identification fabricant) Création: 14/avr./08 14:01 Mise à jour: 15/mai/08 15:22 Résolue: 29/avr./08 10:22 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Sales |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Benjamin Guerville | Attribution: | Florian Ambrosi |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
pro.xls
|
| Pays: |
FRA - France
|
| Description |
|
Bonjour, afin de pouvoir générer des export d'inventaire sans passer par les services de l'équipe param et donc gagner du temps, pourriez-vous rajouter les dimensions suivantes dans la base "FRANCE - ADVERT", répertoire "Product" : - EAN - Identification fabricant MErci BG |
| Commentaires |
| Commentaire de Agathe Remy [ 15/avr./08 15:08 ] |
|
Benjamin, Ces informations ne sont pas encore accessibles dans BI parce que non alimentées. En effet, nous construisons au fur et à mesure une base orientée analyse sur laquelle BusinessObjects effectue ses requêtes. Or toutes les données du site ne s'y trouvent pas encore. Notamment, en raison de l'important projet "Sauvons la base produit", nous avons choisi d'attendre que le modèle de données soit stabilisé avant de l'importer dans BI. Ainsi, nous sommes aujourd'hui dans l'incapacité de vous fournir des informations telles que l'ean ou l'identification du fabricant. Mettre à votre diposition ces informations dans BI représentant donc plusieurs jours de développement, il faut nous fournir une justification business pour pouvoir prioriser cette demande. Merci. Agathe |
| Commentaire de Agathe Remy [ 14/mai/08 15:36 ] |
| Listing des pros classés par nombre d'annonces décroissant |
[IMP-2438] export producd Création: 10/juil./08 15:17 Mise à jour: 30/oct./09 15:42 Résolue: 10/juil./08 16:02 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Jany Marimoutou | Attribution: | Fotigui Tangara |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Login: | producd |
| Séparateur: | Point-virgule (;) |
| Type de traitement: |
N/A
|
| Description |
|
besoin d'une extraction de son inventaire calqué sur la demande PRM-6017 Ne pas oublié la colonne "date de création" Merci |
| Commentaires |
| Commentaire de Fotigui Tangara [ 10/juil./08 16:02 ] |
| Il faudra voir avec Agathe côté BI. Nous ne gérons plus les extractions de stocks. Merci |
| Commentaire de Fotigui Tangara [ 10/juil./08 16:02 ] |
| Je ferme la demande. |
[APP-17094] case abonnement 24h décochée pour les personnes inscrites Création: 16/juil./07 12:27 Mise à jour: 22/mars/10 11:40 Résolue: 24/févr./10 16:15 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | News Letters |
| Affecte la/les version(s): | 15.0.2 |
| Version(s) corrigée(s): | 65.0.0 (TX-M) |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Alexandra Viravaud | Attribution: | Arnaud Forgues |
| Résolution: | Aucune correction envisagée | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
abonne_24h.csv
|
||||||||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Site: | Prod | ||||||||
| Projets PM: | *** RESERVE *** | ||||||||
| Description |
|
Page Mes Abonnements (mise en ligne la semaine dernière) : La case d'inscription aux mails 24h n'est pas cochée pour les personnes effectivement abonnées à cette offre partenaire alors que les personnes concernées continuent bien recevoir les news. Pouvez-vous corriger ca ? Merci Alexandra |
| Commentaires |
| Commentaire de Arnaud Forgues [ 16/juil./07 14:25 ] |
| Alexandra, pourrais-tu préciser le login du compte concerné par ce bug ? Merci |
| Commentaire de Alexandra Viravaud [ 16/juil./07 14:53 ] |
|
tequila2 (alex) ou delnaga (thomas). PS : je viens de remarquer que le BO ne tient pas non plus compte des personnes abonnées à l'offre 24h :( |
| Commentaire de Arnaud Forgues [ 16/juil./07 15:23 ] |
| tequila2 est bien inscrit à 24h en BO comme en FO sur la page "Mes abonnements". Pour delnaga, ce compte n'existe pas en PROD ... ;-( |
| Commentaire de Alexandra Viravaud [ 16/juil./07 16:11 ] |
| un autre exemple (qui devrait marcher cette fois-ci) : bichdao |
| Commentaire de Arnaud Forgues [ 16/juil./07 16:29 ] |
|
si je résume, quand je m'abonne à la news 24h, cela apparait
bien en BO comme en FO et sur le compte "bichdao" cela n'apparait ni en
BO ni en FO alors qu'elle recoit des news de 24h. A priori, je dirais que c'était déjà le cas avant la refonte des abonnements, car on n'a rien changé à ce niveau. Et étant donné que tout à l'air de bien fonctionner pour les nouveaux comptes créé ainsi que pour les modifications d'abonnements, j'ai l'impression qu'il ne s'agit que de certains comptes qui se sont abonné à 24h au tout début du lancement ou qqch comme ça ... quoi qu'il en soit il n'y a aucun évenement lié à l'abonnement à la news 24h dans ce compte ni dans celui de "tequila2" .. Du coup, je ne pense pas que ce JIRA soit critique ... et ensuite je ne vois pas trop comment je pourrais identifier les compte qui recoivent la news 24h alors qu'ils ne sont pas abonnés chez nous... Ce qu'il nous faudrait c'est par exemple que le partenaire (24h) nous envoie le listing de tous les comptes (adresses emails) inscrits chez eux par notre biais afin que l'on resynchronise le tout Passe me voir si tu veux qu'on en discute :D |
| Commentaire de Arnaud Forgues [ 24/juil./07 19:03 ] |
|
en PJ, le fichier de tous les abonnés à 24h via PM. Mais
seuls les utilisateurs avec le code 1394 se sont inscrits via le
formulaire d'inscription ou "Mes abonnements" PM. Il faut donc comparer cette liste aux véritables inscrits à PM en interne et faire éventuellement un script pour synchroniser le tout ! |
| Commentaire de Emeric Teil [ 24/févr./10 16:15 ] |
| 24h n'existant plus, je crois qu'on peut fermer :o) |
[APP-20669] réponse automatique post-vente dvdlegacy Création: 27/mai/08 17:32 Mise à jour: 10/juil./09 10:32 Résolue: 09/juil./09 14:47 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Back-Office |
| Affecte la/les version(s): | 22.1.1 |
| Version(s) corrigée(s): | 49.0.0 (TX-H) |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Natalia Calero | Attribution: | Cedric Favero |
| Résolution: | Invalid | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ESP - Espagne
|
| Site: | Prod |
| Projets PM: | *** RESERVE *** |
| Description |
|
sur le site espagnol, besoin d'une réponse automatique pour toute question post-vente aux Vendeurs : dvdlegacy_es dvdlegacycd Legacybooks la réponse doit être : "Este mensaje es automático: A causa del gran número de pedidos que tramitamos diariamente, te agradecemos que para cualquier duda, te pongas en contacto directamente con PriceMinister a partir de la página de Contacto" Voir la possibilité de pouvoir choisir de faire (depuis le b.o.) ça avec d'autres vendeurs qui ne parlent pas espagnol et/ou qui ne répondent pas systèmatiquement aux messages. |
| Commentaires |
| Commentaire de Charles Decaux [ 04/juin/08 09:35 ] |
|
Hello, cette demande est très importante afin d'améliorer la satisfaction acheteur. En effet, legacy génère plus de la moitié des ventes et ne répond pas aux questions post-achat. Je pense qu'il faudrait également ajouter dans ce mail un lien direct vers le formulaire de contact du SAV. Merci et à votre dispo pour en parler Charles |
| Commentaire de Cantoni Carlos [ 04/juin/08 09:48 ] |
|
cette demande est aussi a prévoir pour le site français ou nous avons le même probleme avec ce vendeur. merci |
| Commentaire de Gaël Seguillon [ 04/juin/08 09:59 ] |
|
Ce serait bien de le faire aussi pour les comptes sur le
site Français qui sont dans la même situation de questions poste ventes
multiples en attente les pseudos de legacy sur la France dvdlegacy dvdlegacy_cd legacy_books Texte en français à transmettre dans les emails Ceci est un message automatique, suite au nombre important de commandes reçues chaque jour le vendeur ne peut répondre aux questions directement, pour une réponse lié à un achat sur ce compte merci de prendre contact directement avec PriceMinister à partir de la page de contact (?) ou (suivi de commande : contactez PriceMinister)(?) |
| Commentaire de Steven Harel [ 04/juin/08 11:06 ] |
|
natalia, peux-tu demander à christophe garcia de te donner les droits pour que des jiras te soient assignés ? en attendant, je réassigne le jira à rocio 1/ je trouve très bizarre le fait de laisser la possibilité aux acheteurs de poser des questions pour leur dire qq minutes plus tard que le vendeur ne répondra pas. donc soit on bloque les questions post vente en back office comme on le fait pour les questions pre vente, soit on y répond. 2/ avant de décider quoi que ce soit, peut-on avoir une idée du type de questions posées ? s'il s'agit de problèmes sur une transaction, de questions sur le fonctionnement du site, ... une fois qu'on aura une idée du type de questions en attente, on pourra décider de ce qu'on fait. pour augmenter la satisfaction des utilisateurs (spécialement important pour l'espagne), je serais a priori d'avis de répondre nous-même aux questions (avec l'accord de dvdlegacy). on pourra alors rassurer les acheteurs, transformer les questions en réclamations si nécessaire, éviter les impayés, avoir une idée plus précise de l'état d'esprit des acheteurs, ... nous avons actuellement 37 questions en attente, ça ne représente donc pas énormément de boulot. |
| Commentaire de Gaël Seguillon [ 04/juin/08 11:10 ] |
| les questions sur le compte français portent principalement sur délais d'expédition et la confirmation de l'expédition mais il n'y répond jamais |
| Commentaire de Steven Harel [ 04/juin/08 11:24 ] |
|
pour ce genre de demande qui implique des procédures back
office + d'éventuels développements, merci de mettre systématiquement
cédric en observateur. aucune décision ne sera prise sans son accord. |
| Commentaire de Natalia Calero [ 04/juin/08 12:09 ] |
| je confirme que sur le site espagnol les questions sont toujours des demandes de confirmation d'expédition, des messages confirmant la non réception des articles ou des messages qu'ils croient être des réclamations en non-reçu. donc monothematique. sauf rarement des précisions sur l'article. |
| Commentaire de Rocio Perez-Garcia [ 04/juin/08 16:33 ] |
| À étudier en COSAV |
| Commentaire de Cedric Favero [ 16/juin/08 18:00 ] |
|
Malheureusement le premier lot des demandes COSAV étant
passé, cette demande ne pourra etre traitée par ce biais rapidement si
elle nécessite un developpement. De plus il ne semble pas évident qu'on accepte un développement s'il n'est pas également justifié pour la France (ex: bloquer pour un compte les questions post/ventes et remplacer par un formulaire contact...) On peut dans l'attente: - répondre nous-même aux questions posées, eventuellement même par un message standard à définir. - ajouter des infos spécifiques à ce vendeur dans les mails "bilan de commande" comme on le fait actuellement pour todoslibros. - au pire , ajouter des infos spécifiques à ce vendeur dans le mail " pas de réponse à votre question" (on envoie pas de mail après l'envoi de la question elle-même) |
| Commentaire de Cedric Favero [ 16/juin/08 18:01 ] |
|
je pense qu'il faut que vous en rediscutiez en réunion Espagne. |
| Commentaire de Charles Decaux [ 18/juin/08 10:15 ] |
|
Vu avec Natalia, on est ok pour ces deux possibilités : - soit pouvoir bloquer les questions post ventes comme on peut le faire aujourd'hui pour les questions pré-ventes. En ajoutant un édito qui propose de contacter directement PriceMinister. - soit envoyer automatiquement un mail à la suite d'une question post-vente indiquant que le vendeur ne répondra pas, mais que l'utilisateur peut contacter PriceMinister. Concernant la France, le besoin existe également, particulierment sur les comptes de legacy (vu et discuté avec Gaël).. Temporairement, on peut répondre au messages manuellement, mais ce n'est pas viable à long terme quand on aura plus de volume. Merci et à votre dispo pour en parler. |
| Commentaire de Cedric Favero [ 18/juin/08 16:17 ] |
|
Ok on part donc sur une solution dev , le besoin existant aussi pour la France. On considère comme acceptable dans l'attente de répondre manuellement aux questions posées? Concernant les solutions: " soit envoyer automatiquement un mail à la suite d'une question post-vente indiquant que le vendeur ne répondra pas, mais que l'utilisateur peut contacter PriceMinister. " => Pas utile de laisser envoyer un mail si c'est pour lui dire que vendeur va pas y répondre Besoin n'existe pas par ailleurs d'avoir un mail envoyé après chaque question posée "soit pouvoir bloquer les questions post ventes comme on peut le faire aujourd'hui pour les questions pré-ventes. En ajoutant un édito qui propose de contacter directement PriceMinister. " => Meilleure solution car besoin existe aussi sur FR pour certains comptes pro. Consisterait donc en une case à cocher (plutot par le commercial que le pro lui-meme) qui interdirait les post-ventes pour le compte avec eventuellement un texte expliquant que le vendeur ne répond pas aux questions et que l'utilisateur doit contacter PriceMinister directement. On va donc pousser cette demande dans le cadre du COSAV pour FR comme ES |
| Commentaire de Natalia Calero [ 18/juin/08 17:08 ] |
|
Je confirme la nouvelle procédure temporaire mise en place depuis aujourd'hui : La personne chargé de faire l'Espagne (Juan, Rocío et moi selon le jour) répondra aux questions post-vente posées aux comptes dvdlegacy_es dvdlegacycd Legacybooks avec la réponse type: ****** Debido a un incremento en nuestra actividad, no vamos a poder contestar a tu mensaje. Si tu pregunta está relacionada con el envío o los plazos de entrega, te confirmamos que puedes hacer una reclamación a partir de tu cuenta. Para ello, debe haber pasado un mes desde la fecha de compra. Te recordamos que el plazo máximo para efectuar una reclamación es de 6 semanas. Si tu pregunta es referente a otros temas, te agradecemos que contactes con PriceMinister a partir de la página de "contacto" indicando el número de la transacción. ****** Je n'hésiterai pas à commenter le jira si la tâche devient ingérable. |
| Commentaire de Cedric Favero [ 19/juin/08 15:30 ] |
|
Pour plus de lisibilité pour les dev , j'ai créé un sous-JIRA: APP-20904. Demande portant donc sur le fait de pouvoir bloquer en BO les questions post/ventes pour un compte donné. |
| Commentaire de Cedric Favero [ 08/juil./09 13:32 ] |
|
DvdLegacy étant mort, on peut fermer cette demande. La fonctionnalité pour refuser les questions post-ventes existent, il faut simplement modifier les pages et éditos lorsque celle-ci est activée. (demande COSAV identifiée bientot priorisée) |
[APP-17301] Supprimer l'ancienne table FRIEND_MAIL Création: 26/juil./07 10:55 Mise à jour: 02/oct./07 18:01 Résolue: 28/sept./07 10:42 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Parrainage |
| Affecte la/les version(s): | 17.0.0 |
| Version(s) corrigée(s): | 17.0.0 |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Alexandre Garnier | Attribution: | Alexandre Garnier |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Projets PM archivés: | Parrainage (refonte) |
| Description |
|
Supprimer la table FRIEND_MAIL qui est devenue obsolète.
|
| Commentaires |
| Commentaire de Alexandre Garnier [ 03/sept./07 15:55 ] |
| On la supprime comme ça ou on l'archive ou elle l'est déjà avec la base du BI ou la table sponsorship (qui contient les anciennes lignes de friend_mail) suffit ? |
| Commentaire de Quentin de Chivré [ 21/sept./07 11:11 ] |
|
A mon sens le fait qu'on a migré dans la nouvelle table suffit. On peut donc tout dropper. |
| Commentaire de Alexandre Garnier [ 28/sept./07 10:42 ] |
|
V17_0_0_ |
[BIN-456] Donner accès au rapport "Buyers distribution by purchase count" à Natalia Création: 06/juin/08 16:22 Mise à jour: 09/juin/08 11:23 Résolue: 09/juin/08 11:23 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Charles Decaux | Attribution: | Agathe Remy |
| Résolution: | Invalid | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Hello, Natalia travaille sur certaines problématiques de fidélisation sur l'Espagne. Dans ce cadre, elle a besoin d'accéder au rapport "Buyers distribution by purchase count" qui se situe dans mon dossier. Pouvez-vous faire en sorte qu'elle puisse y accéder ? Merci |
| Commentaires |
| Commentaire de Agathe Remy [ 09/juin/08 11:23 ] |
|
Je pense qu'il suffit de prendre le temps de montrer à Nathalia comment accéder à BI via le user ur marketing. Agathe |
[IMP-2797] Correction Name Space - pseudo electropromo - Renseigner le name space sur les 1600 FP de son inventaire Création: 30/oct./08 13:58 Mise à jour: 30/oct./09 15:42 Résolue: 03/nov./08 18:53 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Frederic vacher | Attribution: | Frédéric Nahum |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Login: | electropromo |
| Séparateur: | Point-virgule (;) |
| Type de traitement: |
N/A
|
| Description |
|
Bonjour, Dans le fichier d'electropromo, il n'y a pas le namesapace ce qui bloque les imports de tous les autres partenaires. Vu avec F.Nahum, nous allons faire une extraction de stock avec id product - Titre et référence fabricant pour pouvoir renseigner les Namespace. Tous les titres des FP ont la même structure : Fabricant - type de produit Modèle. Avec l'extraction de stock ont pourra donc prendre tous les fabricant et les migrer vers les name space grâce à l'ID product. Ex : La Sommeliere - Cave à vin VIP180 Merci. Fred |
| Commentaires |
| Commentaire de Frédéric Nahum [ 30/oct./08 16:41 ] |
| OK j'attend donc l'extraction de stock |
| Commentaire de Gaël Seguillon [ 30/oct./08 19:23 ] |
|
Fred en fait je n'ai pas la possibilité par le BI de faire
cette extraction de fiches produits, car je ne peux que ressortir les
fiches pour lesquelles il a une annonce active celà ne donne pas la
liste des produits créés par lui sans annonce ou ne garanti pas que
toutes les fiches produit sur lesquelles il a une annonce ont été
créées par lui il nous faut un extract dans le process habituel où au
niveau du param vous faites une requête sur la base pour identifier
toutes les fiches produits créées par ce pseudo a ta dispo si ce n'est pas clair merci Gael |
| Commentaire de Frédéric Nahum [ 31/oct./08 15:38 ] |
| ok je vais essayer de me debrouiller |
| Commentaire de Frédéric Nahum [ 03/nov./08 18:53 ] |
| c'est fait j'ai rajouter le namespace pour les fiche produits de electropromo, elle devrait pouvoir etre reutilise pas d'autre partenaire |
[APP-21810] Il manque des brouillages de liens du coté www.priceminister.com/help/ Création: 20/août/08 12:06 Mise à jour: 07/janv./09 16:41 Résolue: 07/janv./09 16:41 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aide en ligne, Référencement |
| Affecte la/les version(s): | 27.0.1.2 |
| Version(s) corrigée(s): | 38.0.0 (TX-D Bis) |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Pierre Bret | Attribution: | Christophe Garcia |
| Résolution: | Corrigé | ||
| Σ Estimation restante: | Non spécifié | Estimation restante: | Non spécifié |
| Σ Temps consacré: | Non spécifié | Temps consacré: | Non spécifié |
| Σ Estimation originale: | Non spécifié | Estimation originale: | Non spécifié |
| Pièces jointes: |
screenshot-1.jpg
|
||||||||||||||||
| Liens des demandes: |
|
||||||||||||||||
| Sous-tâches: |
|
||||||||||||||||
| Pays: |
ALL - Tous
|
||||||||||||||||
| Site: | Prod | ||||||||||||||||
| Projets PM: | *** RESERVE *** | ||||||||||||||||
| Classif FONC: | ref | ||||||||||||||||
| Description |
|
Les pages suivantes comportent des liens non brouillés : http://www.priceminister.com/help/h http://www.priceminister.com/help/fv http://www.priceminister.com/help/h_principle http://www.priceminister.com/help/hs http://www.priceminister.com/help/hb http://www.priceminister.com/help/hw http://www.priceminister.com/help/c N'hésitez pas à nous solliciter pour plus d'info |
| Commentaires |
| Commentaire de Cedric Favero [ 20/août/08 15:31 ] |
|
Euh personnellement , çà ne me parle pas du tout. Swan ou Alexandre , c'est vous qui gérez çà? Ou c'est quelquechose qu'on a pas fait correctement dans infoglue? Merci. |
| Commentaire de Swan Desportes [ 20/août/08 17:28 ] |
|
On n'a jamais brouillé les liens dans l'aide. C'est une nouveauté. C'est à nous de gérer ça. |
| Commentaire de Pierre Bret [ 23/oct./08 14:07 ] |
| Et 3 mois plus tard, où en est cette demande ? |
| Commentaire de Pierre Bret [ 23/oct./08 14:08 ] |
|
En fait ça fait 2 mois .. je sais :) Le lien externe est sur : http://www.priceminister.com/help/hb_vehicle |
| Commentaire de Alexandre Garnier [ 24/oct./08 10:47 ] |
|
Quasi impossible (et risquerait d'être super lourd) de brouiller automatiquement les liens présents dans l'aide. Normalement on se posait pas ce problème car c'était les accès à l'aide qui sont brouillés. Si on veut les brouiller, il va falloir le faire à la mano en passant sur chaque contenu de l'aide pour appeler la méthode de brouillage (et compliquer encore plus la navigation des utilisateurs avec des liens JS...) |
| Commentaire de Pierre Bret [ 24/oct./08 11:13 ] |
|
ok, merci pour ces infos Vu l'origine de la demande, je pense qu'il va falloir se les faire un par un à la mano comme tu dis. Qui est en charge de ces pages là ? |
| Commentaire de Cedric Favero [ 24/oct./08 12:04 ] |
|
C'est nous au BO qu gérons ces pages mais j'aimerais bien
qu'on ne complique pas inutilement tout çà si pas réellement nécessaire. "Normalement on se posait pas ce problème car c'était les accès à l'aide qui sont brouillés. " => Et ce n'est plus le cas? |
| Commentaire de Thierry Leforestier [ 24/oct./08 12:09 ] |
|
C'est toujours le cas, mais nous savons que Google connait
les urls par d'autres biais (liens externes etc.) c'est donc pour cette
raison que nous ne voulons pas créer une navigation alternative dans
l'aide. De plus, la demande émane du Coex... |
| Commentaire de Cedric Favero [ 24/oct./08 12:11 ] |
|
Ben dites moi ce que vous envisageriez de faire et on en parle.. En sachant qu'on est bien obligé de faire des liens... |
| Commentaire de Thierry Leforestier [ 24/oct./08 12:13 ] |
|
Pas de soucis avec le fait de faire des liens, c'est
simplement qu'il faut les brouiller pour éviter le passage de Google sur
les pages liées et une transmission de PageRank inutile. Je pense qu'un rapide point serait nécessaire en début de semaine. J'organise ça. Thierry |
| Commentaire de Cedric Favero [ 28/oct./08 18:01 ] |
|
Un certain nombre de demandes arrivent chez nous pour
modifier les formats de liens dans l'aide (afin de les brouiller) en
suivant la méthode indiquée dans le WIKI. Tout çà est assez lourd et peut etre facilement source d'erreurs. La question est la suivante: est-ce qu'on ne peut pas integrer ce format de lien , s'il est privilégié , directement dans l'éditeur WYSIWYG d'Infoglue? Merci. |
| Commentaire de Cedric Favero [ 28/oct./08 18:04 ] |
|
Ne pas tenir compte de mon précédent message. Puisque çà ne concerne que les liens externes , aucune utilité à la généraliser.. On fait donc à la mano pour ces cas là. |
| Commentaire de Alexandre Garnier [ 03/nov./08 16:02 ] |
|
Petite question : quand vous brouillez les liens à la mano, vous faites quoi ? Parce que théoriquement il devrait vous suffire d'appeler $LinkFormat ou d'utiliser les macros velocity, jamais de brouiller vous-même les liens. |
| Commentaire de Cedric Favero [ 03/nov./08 17:19 ] |
| Ben jusqu'à present on ne faisait rien. On va regarder le Wiki que tu as indiqué. |
| Commentaire de Cedric Favero [ 03/nov./08 17:57 ] |
|
Donc si on veut faire un lien externe vers www.machin.com , il faut faire comme çà ?: $LinkFormat.finalUrl('www.machin.com ', 'win') |
| Commentaire de Alexandre Garnier [ 03/nov./08 18:04 ] |
| Exactement. |
| Commentaire de Alexandre Garnier [ 13/nov./08 18:50 ] |
|
cf jira lié |
| Commentaire de Cedric Favero [ 13/nov./08 19:23 ] |
|
Habib est en train de repasser sur un tout çà et on en a indentifié meme plus. Par contre , question, quid de tous les liens vers Wengo? Est-ce qqch qu'il faut brouiller aussi? |
| Commentaire de Fabrice Feugas [ 13/nov./08 19:29 ] |
|
Oui il faut les brouiller. On avait défini cette règle pendant le projet de mise en avant wengo, mais nous ne l'avions pas appliquée pour l'aide en partant du principe que "les accès à l'aide étaient brouillés". |
| Commentaire de Thierry Leforestier [ 14/nov./08 09:19 ] |
|
Je confirme. Thierry |
| Commentaire de Cedric Favero [ 14/nov./08 09:26 ] |
|
OK c'est noté. On en fait passer une premiere partie rapidement et habib continue sur le reste... |
| Commentaire de Thierry Leforestier [ 25/nov./08 14:47 ] |
|
Savez-vous quand on aura les bons liens pour AssurOne sur cette page : http://www.priceminister.com/help/h_insurance_offer Ne pas oublier de les brouiller également. Thierry |
| Commentaire de Thierry Leforestier [ 25/nov./08 14:48 ] |
|
Peut-on même le brouiller maintenant ce lien assurOne ? ca ne sera plus a faire :) Merci |
| Commentaire de Cedric Favero [ 25/nov./08 15:43 ] |
| On peut effectivement brouiller déjà ce lien (cassé de toute façon) , meme si mauvais et on le changera dès qu'on aura le bon lien. |
| Commentaire de Habib-Sylvain Gourguet [ 25/nov./08 16:01 ] |
|
D'après Lorenzo, le partenariat de PM Auto avec AssurOne n'a
plus cours (depuis près d'un an). Le partenaire de PM Auto est
désormais AssurLand (voir http://www.priceminister.com/info/assurance). Le contenu de cette page est donc obsolète. Il est également prévu que la Technique de PM Auto soit bientôt gérée par Mixad, sauf erreur de ma part. On trouve encore des liens en FO qui dirigent vers ce contenu ? |
| Commentaire de Habib-Sylvain Gourguet [ 10/déc./08 15:10 ] |
|
Je soumets à publication les derniers contenus comportant des liens qui redirigent vers des sites externes. Contenus modifiés sous CMS1. |
| Commentaire de Cedric Favero [ 12/déc./08 09:27 ] |
|
egalerment fait sur UK publié sur cms1 |
| Commentaire de Christophe Garcia [ 07/janv./09 15:16 ] |
|
Peut-on avoir une liste des pages modifiées. Pour info, dans la page /info/assurance, les liens ne sont toujours pas brouillés. Voir screenshot |
| Commentaire de Thierry Leforestier [ 07/janv./09 15:28 ] |
|
Oui, il faut absolument qu'ils soient brouillés ! Thierry |
| Commentaire de Cedric Favero [ 07/janv./09 15:46 ] |
| Les pages /info sont gérées par le param. |
| Commentaire de Cedric Favero [ 07/janv./09 15:47 ] |
|
Pour la liste de tous les liens modifiés , je ne pense pas qu'on ait noté tout çà. Il y avait qques liens vers les sites des impots ou des choses comme çà.. Habib de memoire? |
| Commentaire de Habib-Sylvain Gourguet [ 07/janv./09 16:34 ] |
|
J'ai une liste non exhaustive des contenus modifiés : i_vehicle_refund_contract_detail h_offer_launch i_chrono_label i_no_shipping h_external_service_planetanoo h_insurance_offer auto_alias_1_11_4_2 auto_alias_1_6_6 cs_op_double i_pro_acc_adv new_offer_launch auto_alias_5_35_2_12_2 auto_alias_5_35_1_6_3 auto_alias_5_35_2_12_1 Manque la vingtaine ou trentaine de formulaires de contact sur www comportant des liens vers Wengo... Et depuis ce JIRA, je brouille la totalité des liens qu'il m'est possible de brouiller :) |
[EXP-4435] Extraction de logs Création: 07/juil./08 10:43 Mise à jour: 07/juil./08 11:44 Résolue: 07/juil./08 11:44 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Etude |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Thierry Leforestier | Attribution: | Patrice Boulanger |
| Résolution: | Aucune correction envisagée | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Nous aurions besoin pour le marketing d'une extraction des derniers logs (sur 2 ou 3 jours) avec tous les codes HTTP (200, 3xx, 4xx, 5xx) selon les critères suivants : referrer contenant google url contenant "t=" Merci d'avance, Thierry |
| Commentaires |
| Commentaire de Thierry Leforestier [ 07/juil./08 11:44 ] |
|
Nous avons trouvé d'où vient le problème lié aux données du BI. Inutile donc de faire l'extraction. Thierry |
[APP-21775] [Widget parrainage] Création d'une page d'aide sur le Widget parrainage Création: 14/août/08 11:40 Mise à jour: 08/sept./08 11:18 Résolue: 29/août/08 17:45 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aide en ligne |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 28.0.0 (CTN-F) |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Cedric Favero | Attribution: | Rocio Perez-Garcia |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Pays: |
ESP - Espagne, FRA - France
|
||||||||
| Projets PM: | *** RESERVE *** | ||||||||
| Description |
|
Ajouter une page "Question sur le Widget Parrainage" dans la page Contact/ questions sur le parrainage: http://www.pm.lan/help/c#contact_sponsorship (sera reprise également par un lien "questions frequentes" dans la page "mes filleuls" ) |
| Commentaires |
| Commentaire de Cedric Favero [ 14/août/08 11:48 ] |
| également une page pour lien sur le compteur "filleuls recrutés via Widget" |
| Commentaire de Cedric Favero [ 19/août/08 17:00 ] |
|
Ok, sont donc créées les pages suivantes: http://www.pm.boulard:1580/help/c_sponsorwidget (alias "c_sponsorwidget" ) Pour la page contact / question sur le Widget parrainage. Avec un formulaire éventuelleent pour question spécifique à cette nouvelle fonctionnalité. http://www.pm.boulard:1580/help/i_widgetrecruited (alias "i_widgetrecruited" ) Pour le lien d'explication sur le compteur "Mes filleuls via blog" |
| Commentaire de Cedric Favero [ 19/août/08 17:02 ] |
|
Seb , si tu as des retours... J'attends de ta part l'URL de page de création du Widget. Merci. |
| Commentaire de Cedric Favero [ 22/août/08 15:55 ] |
|
On crée également une page pour popup expliquant comment insérer le code: http://www.pm.boulard:1580/help/i_sponsorwidgetcode (alias "i_sponsorwidgetcode" ) |
| Commentaire de Cedric Favero [ 29/août/08 09:40 ] |
|
Une modif dans i_widgetrecruited: ce n'est pas le nombre de filleuls qui est limité (les compteurs peuvent continuer à tourner meme si depasse 100) => c'est le nombre de coupons pour le parrain qui est limité. On dit donc: Le nombre maximum de coupons qui vous seront alloués grâce aux filleuls parrainés par ce biais est fixé à 100. (on ne dit plus , en plus des 100 (ou 200) autres possibles..) |
| Commentaire de Rocio Perez-Garcia [ 29/août/08 09:50 ] |
| Vale, modifs faites je soumets a pub |
| Commentaire de Cedric Favero [ 29/août/08 17:45 ] |
|
publié sur cms1 V28 CTN-F |
[APP-18626] [OTM] Valeurs d'attribut impossible à fusionner Création: 21/nov./07 17:02 Mise à jour: 04/mars/08 15:33 Résolue: 15/févr./08 15:01 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Back-Office |
| Affecte la/les version(s): | 18.0.0 |
| Version(s) corrigée(s): | 19.2.0 |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Fabien Farache | Attribution: | Matthieu Bene |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
EnsembleDeLogs.TXT
screenshot-1.jpg
|
||||||||||||||||||||||||
| Liens des demandes: |
|
||||||||||||||||||||||||
| Pays: |
FRA - France
|
||||||||||||||||||||||||
| Site: | Integ | ||||||||||||||||||||||||
| Navigateur: | Tous | ||||||||||||||||||||||||
| Projets PM archivés: | OTM (Lot 2) - Valeurs d'attributs - Intégration | ||||||||||||||||||||||||
| Description |
|
Sur l'attribut PMA0000518 (Origine / Pays) lorsque nous
voulons fusionner les 2 valeurs "France" la requête n'aboutie pas et
nous n'avons pas de fichier soumis en import.
|
| Commentaires |
| Commentaire de Matthieu Bene [ 04/déc./07 15:09 ] |
|
NamedQuery interminable dans PrdAttribute : name = "com.babelstore.stock.entity.PrdAttribute.findByAttributeValueKey", queryString = " select prdAttribute from PrdAttribute prdAttribute" + " where prdAttribute.prdAttributeValueKey = :prdAttributeValueKey " 2007-12-04 14:29:20 DEBUG [SQL ] BO:Anonyme - /* named HQL query com.babelstore.stock.entity.PrdAttribute.findByAttributeValueKey */ select prdattribu0_.PRD_ATTRIBUTE_ID as PRD1_5_, prdattribu0_.NUMERIC_VALUE as NUMERIC2_5_, prdattribu0_.PRD_TYPE_CODE as PRD3_5_, prdattribu0_.CONTRACT_ID as CONTRACT4_5_, prdattribu0_.PRD_ATTRIBUTE_DATE as PRD5_5_, prdattribu0_.ROW_VERSION as ROW6_5_, prdattribu0_.PRODUCT_ID as PRODUCT7_5_, prdattribu0_.PRD_ATTRIBUTE_VALUE_KEY as PRD8_5_, prdattribu0_.PRD_ATTRIBUTE_UNIT_KEY as PRD9_5_, prdattribu0_.PRD_ATTRIBUTE_NAME_KEY as PRD10_5_, prdattribu0_.CREATION_DATE as CREATION11_5_, prdattribu0_.CHANGE_DATE as CHANGE12_5_ from PRODUCT_1.PRD_ATTRIBUTE prdattribu0_ where prdattribu0_.PRD_ATTRIBUTE_VALUE_KEY=? 2007-12-04 14:34:18 WARN [TransactionImpl ] - Transaction TransactionImpl:XidImpl[FormatId=257, GlobalId=boulard/27, BranchQual=, localId=27] timed out.status=STATUS_ACTIVE |
| Commentaire de Matthieu Bene [ 04/déc./07 15:09 ] |
| NamedQuery interminable... |
| Commentaire de Edouard Gomez-Vaez [ 05/déc./07 17:30 ] |
|
Manu m'a dit que c'est difficilement corrigible tel quel. --> Voir dans quels cas cette requête est appelée. Pourquoi en fusion aussi ? |
| Commentaire de Fabien Farache [ 24/déc./07 15:49 ] |
| même problème pour l'attribut "Livres / Langue" (PMA0000034) pour fusionner les valeurs "Français" (K81245) et "Français" (PMK0000243) |
| Commentaire de Fabien Farache [ 10/janv./08 13:36 ] |
|
qu'a-t-il été fait ? pouvons nous fusionner ce genre de valeurs via OTM dorénavant ? |
| Commentaire de Matthieu Bene [ 10/janv./08 14:15 ] |
| Les requêtes ont été changées. Sortie en en V19.0.0 |
| Commentaire de Espérance Galouo-Lece [ 08/févr./08 09:59 ] |
|
- Le problème est toujours présent en demandant la
fusion pour l'attribut "Livres / Langue" (PMA0000034) pour fusionner les
valeurs "Français" (K81245) et "Français" (PMK0000243); - Cf. PJ. |
| Commentaire de Matthieu Bene [ 11/févr./08 12:43 ] |
| Requête de récupération des informations pour les fichiers d'import trop longue. Solution : exécuter une seule fois par mapping la requête (récupération des produits compléments et de base dans la même requête) et supprimer la jointure sur prd_attribute_value et prd_attribute_name. Les informations value et name pourront être récupérées par finder. |
| Commentaire de Matthieu Bene [ 11/févr./08 14:46 ] |
|
La requête est implémentée dans MPTAttributeValueQuery : public List getAttributeList(AttributeValueMappingInfo mapping, Boolean bIsComplement) Elle est appelée dans l'action (MPTAttributeValueAction) par le biais du ProductCatalog : public List<PrdAttribute> getAttributeList(List<AttributeValueMappingInfo> mappings, boolean bbIsComplement) |
| Commentaire de Matthieu Bene [ 12/févr./08 12:21 ] |
| Enlever la jointure sur prd_attribute_value et prd_attribute_name ne suffit pas... |
| Commentaire de Matthieu Bene [ 12/févr./08 18:40 ] |
| Récupérer les produits compléments et de base dans la même requête apporte une importante amélioration des performances. Cependant, la fusion de la valeur PMK0000243 vers K81245 pour le nom d'attribut PMA0000034 concerne près de 400.000 produits (plus de 300.000 rien que pour le type Livres). La transaction dans laquelle s'exécute la requête est marquée pour rollback au bout de 5 minutes, avant avoir ramené les produits du type Livres. Pour les fusions concernant un nombre important de produits, il faut donc migrer les produits directement en base et passer par l'outil après. |
| Commentaire de Fabien Farache [ 13/févr./08 09:48 ] |
| Comment pouvons nous savoir que des valeurs concernent un nombre important de produits quand le calcul de celui-ci n'abouti pas et génère une erreur ? |
| Commentaire de Matthieu Bene [ 13/févr./08 10:38 ] |
| La solution est d'effectuer une requête de comptage directement en base. |
| Commentaire de Christophe Garcia [ 14/févr./08 16:57 ] |
|
Edouard, tu confirmes ? Ca me paraît lourd à gérer côté PARAM non ? |
| Commentaire de Fabien Farache [ 14/févr./08 17:07 ] |
|
1) Nous n'avons pas autorisation de requêter la base de prod mais juste la base de reporting 2) S'il faut toujours passer par un autre outil pour faire quelque chose ce n'est pas genial il faut bien l'admettre... Mais fournissez nous les requêtes, ce sera déjà ça de pris :) |
| Commentaire de Edouard Gomez-Vaez [ 14/févr./08 17:13 ] |
|
Nicolas, je confirme, malheureusement... La requête simple (sans filtre sur type ou medium) est : select count(prd_attribute_id) from prd_attribute where prd_attribute_name_key = 'clef du nom d'attribut' and prd_attribute_value_key = 'clef de la valeur d'attribut'; pour rajouter un filtre sur un type : rajouter un and prd_type_code = 'code du type' pour rajouter un filtre sur un medium c'est compliqué, mais faisable : venir me voir. Fabien, cela te parait-il clair ? |
| Commentaire de Matthieu Bene [ 15/févr./08 15:01 ] |
| La requête de récupération des données pour les fichiers d'import de fusion de valeurs d'attributs a été modifiée ce qui apporte un gain important des performances. |
| Commentaire de Fabien Farache [ 15/févr./08 15:57 ] |
| pour les requêtes c'est clair |
| Commentaire de Edouard Gomez-Vaez [ 04/mars/08 15:31 ] |
| Quitte à revoir les exceptions traitons app-18626 et app-19473 en même temps pour éviter ce genre d'affichage. |
[BIN-491] [Finance] : Rapport Payment by Purchase - Carte Quelle Création: 18/sept./08 15:12 Mise à jour: 17/oct./08 17:31 Echéance: 31/oct./08 00:00 Résolue: 17/oct./08 17:31 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Finance |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Claudie Dufresne | Attribution: | Julien Girardet |
| Résolution: | Invalid | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Dalila, Agathe, Comme vu ensemble, les paiements effectués avec la nouvelle carte de paiement Quelle seront associés au type de carte "COFINOGA". Dans le rapport "payment by purchase", pour permettre de distinguer les transactions effectuées avec la carte QUELLE de celles effectuées avec la carte COFINOGA, il est nécessaire d'ajouter dans le rapport une colonne reprenant les 4 premiers numéros de la carte. (les numéros de la carte QUELLE commençant par 5032). merci claudie |
| Commentaires |
| Commentaire de Dalila Belkebir [ 17/oct./08 17:31 ] |
|
Point avec Claudie le 16/10 : les infos comptables seront
envoyés conjointement pour Quelle et Cofinoga (dans un même fichier). => Côté BI nous n'avons donc plus besoin de marginaliser les carte QUELLE parmi les Cofinoga. Le JIRA est donc fermé puisqu''il n'y a rien à faire pour nous .... Dalila. |
[EXP-4110] Imprimante fraudes HS Création: 29/nov./07 15:13 Mise à jour: 10/avr./08 09:27 Résolue: 10/avr./08 09:27 |
|
| Etat: | Fermé |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Sebastien Bruzzone | Attribution: | Stéphane Eccli |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Bonjour, L'imprimante Brother MFC-8820D-printer a des problèmes d'impression depuis des semaines, les feuilles sont systématiquement noircies. Jerome avait vu le problème et m'avait dit qu'il avait contacté une société pour réparer ce problème. ça commence à devenir important car on reçoit des documents de clients et des réquisitions judiciaires et les papiers deviennent de plus en plus illisibles. Merci. Sébastien. |
| Commentaires |
| Commentaire de Sebastien Bruzzone [ 10/déc./07 11:42 ] |
| ça commence à urger, je reçois des papiers de clients et des réquisitions de plus en plus illisibles, ce qui commence à devenir très problématique... |
| Commentaire de Sebastien Bruzzone [ 28/déc./07 15:37 ] |
|
Apparemment c'est un problème de cartouche, il faut commander des cartouches BROTHER DR3000 on est plusieurs à utiliser ce modèle là au backoffice, il faudrait en commander plusieurs Steven confirme que c'est hyper urgent, nous recevons des documents important par le biais de ces imprimantes. |
| Commentaire de Steven Harel [ 28/déc./07 15:53 ] |
|
je confirme l'urgence la cartouche de sébastien a été maltraitée par jérome celle de régis est presque vide plus de fax pour les fraudes c'est plus la possibilité de recevoir des docs pour confirmer les grosses commandes ! |
| Commentaire de Patrice Boulanger [ 28/déc./07 16:41 ] |
|
J'ai fait une demande au commercial d'InMac pour commander 4
cartouches (2 pour MFC-8820D et 2 pour la HL-5130 de Régis). J'attend
son retour ASAP. Merci. |
| Commentaire de Patrice Boulanger [ 21/janv./08 16:33 ] |
| Les toners ont été reçus et installés. |
| Commentaire de Sebastien Bruzzone [ 22/janv./08 14:38 ] |
| ça ne marche pas même après le chargement de la cartouche, les impressions sont toujours noires |
| Commentaire de Jérémie Bennejean [ 28/févr./08 14:20 ] |
|
Le fax de Sébastien est changé. Une imprimante va être commandée lors de la prochaine commande DELL |
| Commentaire de Jérémie Bennejean [ 28/févr./08 14:20 ] |
| En attendant la nouvelle imprimante, il imprime sur celle du rdc. |
| Commentaire de Stéphane Eccli [ 10/avr./08 09:27 ] |
| Nouveau fax, impression sur le copieur, vu avec Steven |
[PMV : Migration des Anciens Vendeurs]
(APP-21971)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 27.0.1 |
| Version(s) corrigée(s): | 31.0.0 (TX-C) |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | Arnaud Forgues | Attribution: | Arnaud Forgues |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Projets PM archivés: | Paiement - Migration anciens vendeurs |
| Description |
|
Dans ce lot, on migre les utilisateurs particuliers
actuellement en privilège SILVER (virement) dont le PMV a déjà été
activé (sauf les vendeurs -2, qui par construction auront déjà été
migrés dans le lot 1) en privilège Platine mode libre sans configuration
des reversement du PMV. Ces utilisateurs seront soumis à une communication par mail des changements liés à cette migration : en effet, ils devront alors configurer une demande de reversement ponctuelle ou régulière par virement afin de recevoir à nouveau les paiements de leurs ventes. |
| Commentaires |
| Commentaire de Arnaud Forgues [ 02/oct./08 15:27 ] |
|
La migration est effective. Le ciblage est en cours au BI et le mailing d'accompagnement sera envoyé samedi prochain. |
[BIN-398] [Tracking] : Mise en place d'un reporting hebdomadaire pour Clubic Création: 21/déc./07 17:55 Mise à jour: 05/févr./08 15:15 Résolue: 08/janv./08 18:49 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Henrieta Bubenkova | Attribution: | Samir Beghdadi |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Je voudrais qu'en plus de l'appel mensuel à facture pour le
tracking 1 "Clubix" les rapports hebdomadaires soient générés et envoyés
avec une fréquence hebdomadaire à l'adresse de notre partenaire. Merci d'avance henrieta |
| Commentaires |
| Commentaire de Henrieta Bubenkova [ 07/janv./08 15:43 ] |
|
Pourrais-tu juste encore ajouter à Clubicx le No de paniers dans les statistiques hebdomadaires stp ? Nous pouvons envoyer les stats hebdo lundi et le 05 dsu mois pour le mensuel merci! |
| Commentaire de Samir Beghdadi [ 08/janv./08 18:49 ] |
|
Agathe, Peux tu valider les spécifications (fonctionnel et technique) pour les rapports de Clubic qui se trouvent dans V:\Reporting\BusinessIntelligence\Evolutions\Clubic. Et les rapports "Clubic - Appel à facture hebdomadaire" et "Clubic - appel à facture mensuel" qui se trouvent dans Public Folders/Development/Marketing/Purchase. Si nécessaire les passer en prod avec une programmation chaque lundi pour l'hebdomadaire et remplacer l'actuel appel à facture Clubic chaque 5 du mois. Merci :-) Samir qui parts en vacance |
| Commentaire de Agathe Remy [ 28/janv./08 15:32 ] |
|
Henrieta, Les rapports "Clubic - Appel à facture mensuel" et "Partner - Weekly revenue by tracking group" ont été livré en Production dans le dossier public France/Purchase. Peux-tu nous dire s'ils te conviennent? Dès que tu les auras validé, Samir pourra programmer leur envoi par mail au partenaire. Merci. Agathe |
| Commentaire de Henrieta Bubenkova [ 30/janv./08 14:52 ] |
|
Je valide le format des rapport Clubicx (mensuel + hebdomadaire) qui se trovent sur BI/Dossiers Publics/Purchase merci! henrieta |
| Commentaire de Agathe Remy [ 30/janv./08 19:13 ] |
|
Samir, Il ne te reste plus qu'à désactiver l'ancien appel à facture et à programmer les 2 nouveaux rapports. Merci:-) Agathe |
| Commentaire de Samir Beghdadi [ 31/janv./08 12:52 ] |
|
Les deux rapports sont programmés: Pour l'hebdo c'est chaque lundi à 12h30 et pour le mensuel c'est comme l'ancien chaque 5 du mois à 8h00. J'ai modifié le corps du mail du rapport hebdomadaire (remplacer "appel à facture du mois dernier" par " le Chiffre d'affaires généré la semaine dernière"). Merci Samir |
[BIN-427] [Tracking] : ajout d'un destinataire pour les appels à facturation mensuels Création: 07/avr./08 12:03 Mise à jour: 14/mai/08 15:24 Résolue: 15/avr./08 14:41 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Partners |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Henrieta Bubenkova | Attribution: | Florian Ambrosi |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Suite à la demande de notre partenaire Pangora je voudrais ajouter un autre destinataire de l'appel à facturation mensuel comme suivi: destinataire actuel: Nicolas Preteceille [Nicolas.Preteceille@pangora.com] nouveau destinataire à ajouter: ariane.kliche@pangora.com Merci Henrieta |
| Commentaires |
| Commentaire de Romain Czornomaz [ 07/avr./08 12:10 ] |
|
Florian, Peux tu traiter la demande? Merci d'avance, Romain |
| Commentaire de Florian Ambrosi [ 07/avr./08 15:05 ] |
|
Romain, J'ai ajouté l'adresse email au destinataire de l'appel à facture mensuel Pangora, mais je crois avoir lancé la tâche par erreur. Florian |
| Commentaire de Agathe Remy [ 15/avr./08 11:16 ] |
|
Mail du 07/04 : "Bonjour, Pouvez-vous mettre Ariane Kliche (comptabilité) en copie de chacun des mails d'appels à factures (ariane.kliche@pangora.com) ? En vous remerciant par avance Cordialement Nicolas Préteceille Key Account Manager France " |
| Commentaire de Agathe Remy [ 15/avr./08 11:18 ] |
|
Henrieta, Veux-tu que nous nous en occupions? Agathe Mail du 10/04 : "Bonjour Henrieta, Je vous remercie pour l'ajout d'Ariane Kliche dans la liste des destinataires. Pouvez-vous me faire parvenir l'intégralité des appels à factures depuis Août 2007 ? En vous remerçiant par avance Cordialement Nicolas Préteceille Key Account Manager France" |
| Commentaire de Agathe Remy [ 15/avr./08 14:39 ] |
|
Merci bcp Agathe, je l'ai déjà fait en leur envoyant les appels mensuels de l'historique dans BI. henrieta |
[BIN-395] [Business Objects] Demande de filtre dans France-Purchase Création: 11/déc./07 17:59 Mise à jour: 17/déc./07 11:20 Résolue: 17/déc./07 11:20 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Cedric Favero | Attribution: | Agathe Remy |
| Résolution: | Invalid | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
screenshot-1.jpg
|
| Pays: |
FRA - France
|
| Description |
|
Serait-il possible d'ajouter dans France-Purchase un filtre
pour savoir si un panier est passé en observation et s'il y a eu une
confirmation manuelle. A moins que j'ai mal regardé et que çà existe déjà. Cf capture pour les deux états. Merci. |
| Commentaires |
| Commentaire de Agathe Remy [ 17/déc./07 11:20 ] |
|
Cette demande consiste à idenitifer les paniers capturés
passés par les statuts OBSERVATION, puis confirmés manuellement. Cela revient à restituer l'historique des évènements d'un panier. Ceci n'est actuellement pas possible via BI. Cordialement, Agathe |
[APP-21774] [Widget parrainage] Création d'un article supplémentaire dans le reglement parrainage Création: 14/août/08 11:27 Mise à jour: 08/sept./08 11:18 Résolue: 29/août/08 17:44 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aide en ligne |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 28.0.0 (CTN-F) |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Cedric Favero | Attribution: | Cedric Favero |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Ajout_parrainage(fraudes).rtf
parrainage_widget.rtf
spec_widgetparrainage_v0 6 (2).doc
|
||||||||
| Liens des demandes: |
|
||||||||
| Pays: |
ESP - Espagne, FRA - France
|
||||||||
| Projets PM: | *** RESERVE *** | ||||||||
| Description |
|
Doit etre ajouté un article dans le reglement parrainage pour ce qui concerne le widget parrainage. Indiquer que, comme pour les autres parrainages ,le parrain (et donc possesseur du widget) ne doit pas tenter de se parrainer lui-même. Que ne seront validés les coupons que si les filleuls sont eux-même élligibles. Que le nombre de filleuls maximum acquis par le widget est limité à 100 (compteur dispo sur son compte) Je vois avec Benoit pour la rédaction de cet article. |
| Commentaires |
| Commentaire de Cedric Favero [ 14/août/08 11:28 ] |
| en PJ les derniers specs du projet |
| Commentaire de Cedric Favero [ 19/août/08 17:03 ] |
| Modif reglement par Benoit |
| Commentaire de Cedric Favero [ 19/août/08 17:44 ] |
|
Plutot que créer un article supplementaire , je l'ai inclus dans l'article 3. Ca me semble suffisant comme çà: http://www.pm.boulard:1580/help/r_sponsorship |
| Commentaire de Cedric Favero [ 21/août/08 10:26 ] |
|
Ok c'est bon , j'en ai profité pour ajouter les éditos demandés par les Fraudes. Toutes les modifs de contenus sont dans l'Article 3 - Modalités de participation. J'en ai aussi profité pour tous les articles pour changer les "auto-alias". On verra ensuite si on change la structure (tous articles dans une meme structure) ( cf |
| Commentaire de Cedric Favero [ 21/août/08 10:27 ] |
|
Rocio , c'est bon , tu peux traduire les modifs (article 3) Merci. |
| Commentaire de Cedric Favero [ 25/août/08 14:30 ] |
|
Pour info, L'article 3 ne contient des infos sur le Widget parrainage que dans le content version WWW (car ne s'applique pas aux cobrandings) |
| Commentaire de Rocio Perez-Garcia [ 25/août/08 17:47 ] |
| Modifications faites sur ES. Je te laisse gérer pour la publication. |
| Commentaire de Cedric Favero [ 28/août/08 17:21 ] |
|
Désolé mais encore quelques modifs à traduire. Tjrs sur WWW , article 3 , on change notamment: "Tout membre pourra devenir parrain via 2 types de parrainage : - Par le parrainage classique: Soit le membre remplit sur le site le formulaire de parrainage prévu à cet effet, dans lequel il précisera les adresses électroniques des internautes qu'il désire parrainer : ces internautes recevront alors un mail de leur part contenant un lien incluant un code identifiant le Parrain pointé vers la page d'accueil du Site. Soit le membre transmet un mail, que $brandDto.brandName lui aura adressé, aux personnes de son choix, avec un lien incluant un code identifiant le Parrain pointé vers la page d'accueil du Site. - Par le Widget Parrainage : Le membre insère cet outil sur un service de communication au public en ligne dont il est l'éditeur." puis "Un parrain pourra parrainer au maximum 100 filleuls par type de parrainage." et enfin: "Un Parrain pourra parrainer au maximum 100 Filleuls par le biais du Widget Parrainage, en plus des 100 permis par le parrainage classique. " |
| Commentaire de Rocio Perez-Garcia [ 29/août/08 09:23 ] |
|
Cédric, j'ai soumis à publication seulement les contents,(attention) aussi le FR et wwwFR. Je ne mets pas ce Jira à publier sur IG car la structure est en working et sais pas laquelle tu vas laisser. A publier: /online_help/Help Articles/Folder Règlements/Folder Règlement du programme de Parrainage de $brandDto.brandName/ARTICLE 3 - MODALITES DE PARTICIPATION - Spanish (Spain) (245332) /online_help/Help Articles/Folder Règlements/Folder Règlement du programme de Parrainage de $brandDto.brandName/ARTICLE 3 - MODALITES DE PARTICIPATION - WWW France (246195) /online_help/Help Articles/Folder Règlements/Folder Règlement du programme de Parrainage de $brandDto.brandName/ARTICLE 3 - MODALITES DE PARTICIPATION - French (French) (245318) |
| Commentaire de Cedric Favero [ 29/août/08 09:35 ] |
|
De toute façon quand je soumets , je soumets en meme temps la structure et tous les contenus associés.. Bon, par contre , il semblerait en fait que nombre de coupons possibles par parrainage classique soit de 200 dont au total 200+100 = 300 :-( On tire çà au clair avant de refaire des modifs.. |
| Commentaire de Cedric Favero [ 29/août/08 17:44 ] |
|
publié sur cms1 V28 CTN-F |
[APP-20921] [Fraudes] demande pour obtenir les fonctionnements de différents types de coupons Création: 20/juin/08 11:50 Mise à jour: 22/mars/10 11:58 Résolue: 17/févr./10 14:05 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Coupons |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 65.0.0 (TX-M) |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Cedric Favero | Attribution: | Clement Balay |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Types_Coupons.pdf
|
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM: | *** RESERVE *** |
| Classif2: | Self service Coupons |
| Description |
|
Dans le but d'améliorer nos systèmes anti-fraudes, il nous
faudrait les comportements exacts des types de coupons différents: - STANDARD - FIRST_COUPON - FILLEUL - PARRAIN - LOTTERY - LOTTERY_FIRST En effet, il apparait qu'ils n'aient pas tous les memes verifications et niveau de sécurité quant aux droits d'utilisation. On voudrait donc savoir pour chacun ce qu'il verifie exactement: IP , adresse de livraison , hash CB , etc... Merci |
| Commentaires |
| Commentaire de Cedric Favero [ 24/juin/08 09:35 ] |
|
Suis pas certain que celà doive passer par le pole TX. Il ne s'agit pas d'un developpement mais uniquement d'une demande d'information détaillée. Ne peut-on simplement nous répondre sur ce point? |
| Commentaire de Emeric Teil [ 25/août/08 15:53 ] |
| Je mets en PJ, un petit doc sur les différents types de coupons. Cependant, cela ne répond pas à la question en détail, pour cela, voir si un Dev a l'historique la dessus... |
| Commentaire de Arnaud Forgues [ 28/août/08 17:13 ] |
|
Je renvoie chez Dispatcher-Dev pour un meilleur dispatch car je n'ai pas l'historique là-dessus. A voir en COJIRA |
| Commentaire de Martin Sudmann [ 04/sept./08 18:21 ] |
|
- STANDARD : on teste rien (le coupon est libre à être utilisé par la personne à qui il a été attribué - FIRST_COUPON : on vérifie que l'utilisateur n'a encore jamais acheté (on essaye de trouver des articles / paniers avec ces données) - FILLEUL : on vérifie que l'utilisateur n'a jamais encore acheté - FILLEUL - PARRAIN : on vérifie que les deux ne soient pas identiques - LOTTERY : attribué manuellement (à ma connaissance), donc pas de vérifs - LOTTERY_FIRST : comme first coupon sur l'écran d'un coupon il y a aussi tout un tas d'explications sur les règles métier du coupon. Ca réponds à tes questions ? |
| Commentaire de Martin Sudmann [ 04/sept./08 18:22 ] |
| pour plus de détail il faudrait passer du temps le nez dans le code... |
| Commentaire de Cedric Favero [ 04/sept./08 18:33 ] |
|
Merci pour tes réponses. Malheureusement , c'est le détail des verifications exactes qu'il me faudrait.. Pour lever le doute sur un certain nombre d'idées reçues. Pour ce qui est de l'écran coupon, il y a effectivement un certain nombre d'indications mais çà ne dit pas exactement ce que fait le type de coupon. En particulier, j'aurais besoin de détails sur: "FIRST_COUPON : on vérifie que l'utilisateur n'a encore jamais acheté (on essaye de trouver des articles / paniers avec ces données) " => est-ce qu'on ne vérifie que la carte (hash cb) ou est-ce qu'on a aussi un test sur l'IP ? ou autre chose (nom+prenom+adresse)? "- FILLEUL : on vérifie que l'utilisateur n'a jamais encore acheté " => meme question: quelles données exactement sont testées? La carte uniquement? Car si je regarde un coupon comme ALPACINO , on voit qu'il peut etre utilisé meme si on a déjà acheté. "- FILLEUL - PARRAIN : on vérifie que les deux ne soient pas identiques" ??? Quel check est fait et à quel moment? Tu veux dire qu'on refuse le coupon si le filleul veut acheter à son parrain? Sur quelles bases? A ma connaissance , la seule verif qui est faite par un coupon filleul , c'est s'il n'a pas déjà acheté chez nous mais pas s'il correspond en qqch à son parrain (d'où l'interet de rapports BI à posteriori pour matcher les IP , les mots de passe, les date de naissance, etc...) |
| Commentaire de Cedric Favero [ 04/sept./08 18:40 ] |
|
Malheureusement, c'est bien ce qui est dans le code qui m'interesse, et pas juste ce qu'on pense qu'il fait. Les rapports qu'on a pu faire sur les parrainages, l'utilisation des coupons, etc.. fait apparaitre un certain nombre de failles.. Et pour y remédier , il faut qu'on puisse partir sur des bases saines et donc etre certain de ce que font exactement tels ou tels coupons. En gros , j'aurais besoin pour chaque type de savoir les checks effectués (hash CB , IP ? adresse ?, nom ? mot de passe ? ..) Merci d'avance si ce n'est pas trop complexe. |
| Commentaire de Martin Sudmann [ 04/sept./08 18:43 ] |
| Il faut donc creuser le code ; le pôle TX s'en fera un plaisir. |
| Commentaire de Cedric Favero [ 04/sept./08 18:47 ] |
|
La patate chaude :-) Désolé les gars mais trop d'incertitudes , j'ai besoin de concret. Merci à qui aura un peu de temps.. |
| Commentaire de Emeric Teil [ 18/déc./08 14:58 ] |
| A regarder à l'occasion de l'étude technique pour le projet Self Service Coupons ? |
| Commentaire de Cedric Favero [ 18/déc./08 15:05 ] |
|
Apres qques tests perso: - FILLEUL - PARRAIN : ne fonctionne pas lorsque IP parrain et filleul sont identiques. Apparemment verification de l'adresse également (tous les champs adresse?) Meme quand le coupon parrain est refusé à cause de çà , le coupon filleul n'est pas remis en cause. Donc le mec qui s'auto-parraine bénéficie quand meme du coupon ALPACINO (meme si CORLEONE refusé). Bcp de choses à revoir.. |
| Commentaire de Emeric Teil [ 18/déc./08 15:06 ] |
| Oui, enfin la demande en question de regarder comment ça fonctionne pas de tout remettre en cause... |
| Commentaire de Cedric Favero [ 18/déc./08 15:09 ] |
|
Chaque chose en son temps ;-) Déjà si on me donne les clés de l'existant , çà levera un grand voile d'inconnu et de flou.. Merci. |
| Commentaire de Cedric Favero [ 19/déc./08 16:44 ] |
|
En passant, exemple flagrant; http://bo.priceminister.com/user_back?action=usersearch&email=bene.flouriot%40caramail.com&fuzzy=false&numberrows=200 Grace à une ECB non détectée la personne a pu faire 148 achats avec coupon! Les coupons premier achat pourraient au moins vérifier l'adresse email en plus. |
| Commentaire de Clement Balay [ 19/févr./09 18:44 ] |
| J'ai crée un wiki qui explique un peu les coupons, ce WIKI n'est pas exhaustif. Dis moi si tu as encore des questions |
| Commentaire de Clement Balay [ 19/févr./09 18:45 ] |
| http://ruinart.lan:4080/pricewiki/Wiki.jsp?page=FonctionnementDesCoupons |
[BIN-410] [Sales] : Seller commission title - vide Création: 15/févr./08 18:00 Mise à jour: 22/avr./08 15:55 Résolue: 28/févr./08 14:07 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Sales |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Benjamin Guerville | Attribution: | Agathe Remy |
| Résolution: | Invalid | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Description |
|
Hello, Je travaille sur un rapport faisant ressortir le type de commission : Favoris/Benjamin/Rapport général VA CA Parfois il n'y a pas de valeur pour cet objet alors qu'il devrait forcément en avoir un (ex : PRO:15%Fixe, PRO:8%Fixe, etc...) Ca me pose des problèmes pour traiter les données correctement du coup. Merci |
| Commentaires |
| Commentaire de Agathe Remy [ 28/févr./08 14:07 ] |
|
Benjamin, Après étude, il n'y a pas de bug au niveau BI : il existe bien des transactions ou des vendeurs qui ne sont associés à aucune classe de commission. A priori, cela ne devrait plus exister aujourd'hui, puisque le volumes ont fortement diminué depuis août 2007 : date_creation nb_transactions_capturees_sans_com 01/12/2007 1 01/06/2007 1 01/02/2007 1 01/10/2005 5 01/08/2004 1947 01/07/2004 3745 01/06/2004 3136 01/05/2004 2580 01/04/2004 110231 01/03/2004 139731 01/02/2004 133609 01/01/2004 142672 01/12/2003 138670 01/11/2003 129825 01/10/2003 120460 01/09/2003 105735 01/08/2003 86343 01/07/2003 80939 01/06/2003 78466 01/05/2003 86124 01/04/2003 86889 01/03/2003 86916 01/02/2003 78037 01/01/2003 77037 01/12/2002 73154 01/11/2002 68752 01/10/2002 57858 01/09/2002 48991 01/08/2002 41172 01/07/2002 35745 01/06/2002 31958 01/05/2002 32353 01/04/2002 26904 01/03/2002 27601 01/02/2002 21653 01/01/2002 22225 01/12/2001 14944 01/11/2001 11913 01/10/2001 8594 01/09/2001 5719 01/08/2001 4447 01/07/2001 2890 01/06/2001 2126 01/05/2001 1500 01/04/2001 887 01/03/2001 416 01/02/2001 65 01/01/2001 13 Ne pouvant pas inventer des données qui n'existent pas, je ne peux pas faire grand chose... Une petite remarque : je te conseille d'utiliser la dimension Item/Item commission label plutôt que Seller account/Seller compensation/Seller commission title. En effet, la première correspond à la classe de commission appliquée lors de la transaction, alors que la seconde correspond à la classe de commission actuelle du vendeur. Je reste à ta disposition si tu as des questions. Agathe |
| Commentaire de Agathe Remy [ 28/févr./08 15:24 ] |
|
Benjamin, Dans le BackOffice, il y a possibilité d'affecter une classe de commission "Aucun" à un vendeur, ce qui a pour impact de passer la classe du vendeur à "NULL" dans la base. Après étude, seul des vendeurs pros ont été affecté à cette valeur. Pourrais-tu me dire dans quel cas vous réalisez ce genre d'opération? Merci. Agathe |
| Commentaire de Benjamin Guerville [ 28/févr./08 15:27 ] |
| ça ne me dit rien, tu as des exemple de vendeurs stp ? |
| Commentaire de Agathe Remy [ 28/févr./08 15:52 ] |
|
user_account_id;login 64463;infowmg 3431570;directprice 4047547;Rafty 4141134;Lecritoire 4571647;ecolivres 4755098;PhoneCash 5324416;pass-tek 7741888;lapiere 10420139;CORTEX_REC 10674243;ggechevalier 11193618;bonprix8 11642863;micaba 12396758;vinyl74 12763933;CONTESDOR |
| Commentaire de Agathe Remy [ 18/avr./08 19:41 ] |
|
Benjamin, Des nouvelles sur la classe de commission "Aucun"? Merci. Agathe |
| Commentaire de Benjamin Guerville [ 21/avr./08 19:17 ] |
|
Il s'agit essentiellement de comptes en -2, en vacances, inactifs, bloqués... Souhaites-tu que je modifie le "Aucun" en "Particulier" par exemple ? |
| Commentaire de Agathe Remy [ 21/avr./08 19:45 ] |
|
En effet, cela permettrait de résoudre les problèmes de reporting. En revanche, je me demande s'il ne faut pas demander à l'équipe Développement de supprimer cette classe "Aucun". Qu'en penses-tu? Agathe |
| Commentaire de Benjamin Guerville [ 22/avr./08 14:04 ] |
|
ok je modifie les "aucun" et fait un Jira pour le supprimer. merci |
| Commentaire de Agathe Remy [ 22/avr./08 15:55 ] |
|
Suite à l'ouverture du JIRA APP, je ferme celui-ci. Merci. Agathe |
[APP-22652] [PMV] Incohérence sur l'état du PMV de certains utilisateurs Création: 21/oct./08 13:58 Mise à jour: 07/janv./09 11:17 Résolue: 31/déc./08 15:12 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 31.0.3 |
| Version(s) corrigée(s): | 38.0.0 (TX-D Bis) |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Arnaud Forgues | Attribution: | Arnaud Forgues |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM: | *** CHASSE *** |
| Description |
|
Certains utilisateurs devraient avoir un PMV restreint et sont en Ouvert-intégral et vice-versa. Incohérences à analyser et corriger SQL> select count(*) from user_account where wlt_status_code = 30 and wallet_outgoing_amount = 0; COUNT(*) ---------- 5 Ecoulé : 00 :00 :13.49 SQL> select user_account_id from user_account where wlt_status_code = 30 and wallet_outgoing_amount = 0; USER_ACCOUNT_ID --------------- 8431904 12464064 15447010 16910520 17128378 Ecoulé : 00 :00 :02.55 SQL> select count(*) from user_account where wlt_status_code = 10 and wallet_outgoing_amount <> 0; COUNT(*) ---------- 3885 |
| Commentaires |
| Commentaire de Arnaud Forgues [ 01/déc./08 19:21 ] |
|
Concernant les 9 utilisateurs suivants, j'ai appliqué la
méthode du "Bolcage/Déblocage" du PMV afin de repositionner l'état du
PMV correctement ==> Ouvert-intégral : SQL> select user_account_id, usr_visibility_code from user_account where wlt_status_code = 30 and wallet_outgoing_amount = 0; USER_ACCOUNT_ID USR_VISIBILITY_CODE --------------- ------------------- 6245372 -2 12464064 1 16454730 1 4300037 -2 8431904 1 15517247 1 15997195 -2 17128378 1 17371804 -2 La désynchro venait dans la plupart des cas d'un bug corrigé en TX-C mais qui avait laissé des cas non migrés à ce moment-là. Pour le cas inverse (PMV Ouvert-intégral avec un montant sortant différent de 0), le cas peut en fait se produire lors d'un débit non FO en cours (ex.: Débit achat, ou Debit-PM ou encore avec l'opération systématique d'un compte compta), au final un seul cas se révèle illogique : voir le compte 598891 (nanette26) select user_account_id, wallet_outgoing_amount from user_account where user_account_id IN ( select u.user_account_id from user_account u where u.wlt_status_code = 10 and u.wallet_outgoing_amount <> 0 MINUS select u.user_account_id from user_account u where u.wlt_status_code = 10 and u.wallet_outgoing_amount <> 0 AND EXISTS(SELECT 1 FROM operation o WHERE o.user_account_id = u.user_account_id AND o.opr_type_code = 70 AND o.opr_status_code = 20) MINUS select u.user_account_id from user_account u where u.wlt_status_code = 10 and u.wallet_outgoing_amount <> 0 AND EXISTS(SELECT 1 FROM operation o WHERE o.user_account_id = u.user_account_id AND o.opr_type_code = 80 AND o.opr_status_code = 30) MINUS select u.user_account_id from user_account u where u.wlt_status_code = 10 and u.wallet_outgoing_amount <> 0 AND EXISTS(SELECT 1 FROM operation o WHERE o.user_account_id = u.user_account_id AND o.opr_type_code IN (60,90,100) AND o.opr_status_code IN (20,30,70) AND o.is_generated_by_system = 1 AND u.cmp_is_direct_payment = 1) ) |
| Commentaire de Arnaud Forgues [ 01/déc./08 19:22 ] |
| Je laisse donc le SAV voir s'il y a quelque chose à faire de spécifique pour ce compte, car en regardant l'historique des opérations et les evenements du PMV, je ne comprend pas comment ce compte peut avoir un montant sortant du PMV différent de 0 |
| Commentaire de Cedric Favero [ 15/déc./08 09:41 ] |
|
Claire, tu peux regarder le compte de nanette26 et retrouver à quelle opération pourrait correspondre les 4.42¿ sortants? Et s'il n'y a rien de particulier avec cette opération.? Merci. |
| Commentaire de Cedric Favero [ 15/déc./08 10:29 ] |
|
a vu d'oeil on ne retrouve pas.. Une requete Bi nous donne les opérations suivantes pour un montant de 4.42. Il s'agit des debits PMV pour achats: 3269051 DEBIT_PURCHASE COMPLETED 4243470 DEBIT_PURCHASE COMPLETED 4737255 DEBIT_PURCHASE COMPLETED 7035566 DEBIT_PURCHASE COMPLETED 7823714 DEBIT_PURCHASE COMPLETED 8041473 DEBIT_PURCHASE COMPLETED Voir si qqch de bizarre. |
| Commentaire de Claire Durand [ 15/déc./08 18:00 ] |
|
j'ai vérifié toutes les opés de cédric et n'ai rien trouvé d'anormal par contre en effectuant une recherche bo dans les différents types de débit, je ne retrouve pas cette ope c claire ? |
| Commentaire de Arnaud Forgues [ 30/déc./08 12:15 ] |
|
Les explications de Claire sont claires ! Mais j'ai cherché également de mon côté : en BDD ... et je n'ai rien trouvé qui explique cela. Que souhaitez vous que l'on fasse avec ces 4¿ et quelques ? - On peut remettre le montant sortant à 0, mais du coup cela sera au bénéfice de l'utilisateur. - autres ...? |
| Commentaire de Cedric Favero [ 30/déc./08 13:45 ] |
|
Agathe n'était pas venu te voir pour des pbs similaires? |
| Commentaire de Arnaud Forgues [ 30/déc./08 14:22 ] |
|
Non je ne crois pas! Je te laisse réattribuer ce JIRA à
Agathe si tu penses qu'elle a plus d'infos, sinon j'attend vos retours
pour faire ce que l'on décide. Merci |
| Commentaire de Cedric Favero [ 30/déc./08 18:02 ] |
|
vu que ce n'est qu'un compte et qu'en plus il a fait des
dizaines de milliers d'euros d'achat chez nous , je crois qu'on va faire
au plus simple :-) Remettons le montant sortant à 0 donc. |
| Commentaire de Arnaud Forgues [ 31/déc./08 15:12 ] |
|
Ok ! Le script "V38_0_0_APP_22652_ALL_01_user_account_fix_wallet_outgoing_amount.sql" passera donc en INTEG puis en PROD pour la TX-D bis |
[INF-162] Arrivée de Corinne GRONDIN Création: 23/sept./08 17:39 Mise à jour: 06/oct./08 10:48 Résolue: 06/oct./08 10:48 |
|
| Etat: | Fermé |
| Projet: | Infrastructure |
| Composants: | Arrivée/Départ |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Gafour Abdoul | Attribution: | Christophe Garcia |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
FICHE NOUVEL ARRIVANT.doc
|
| Description |
|
Préparation de l'arrivée de Corinne GRONDIN
|
| Commentaires |
| Commentaire de Gafour Abdoul [ 23/sept./08 17:57 ] |
|
Salut Stéphane, Concernant le PC de Corinne, je souhaiterais pour elle une machine avec plus de RAM (nous avons Paul et moi 2Go), le maximum de winXP est de 3Go je crois. Pour les logiciels ils lui faudrait : - la suite Adobe CS3 (ça ne posera pas problème si Paul et moi ne l'avons pas en même temps. on devrait pouvoir lui faire l'installation au pire) - la suite office bien sûr Pour le matériel : - un PC Bi-écran - une machine fraichement installée A priori c'est tout. Merci |
| Commentaire de Stéphane Eccli [ 03/oct./08 14:45 ] |
| comptes ok, reste Jira |
| Commentaire de Christophe Garcia [ 06/oct./08 10:48 ] |
| fait |
[APP-22009] [Alerte - DEV USER - TX - (3)] - A user (n° 517503) without activation code trying to access to inventory activation - From url : /user?action=sellerprofile Création: 04/sept./08 18:18 Mise à jour: 10/oct./08 17:22 Résolue: 04/sept./08 18:28 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 26.0.2 |
| Version(s) corrigée(s): | 31.0.0 (TX-C) |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Renaud Dierickx | Attribution: | Arnaud Forgues |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM: | *** CHASSE *** |
| Commentaires |
| Commentaire de Renaud Dierickx [ 04/sept./08 18:25 ] |
|
Ces alertes se produisent pour les anciens utilisateurs
n'ayant pas de code d'activation mais ayant déjà ouvert leur boutique... Ce n'est donc pas un problème mais plutôt une alerte non cohérente. J'ai corrigé ces alertes en les générant uniquement pour les utilisateurs n'ayant pas ouvert leur boutique ET n'ayant pas de code d'activation. C'est donc corrigé ! |
| Commentaire de Cédric Goldovsky [ 09/oct./08 11:37 ] |
|
Par quel biais puis-je générer cette alerte ? Par exemple pour le compte btapie/creditl je ne vois pas comment faire apparaitre cette erreur ? Merci :-) |
| Commentaire de Espérance Galouo-Lece [ 10/oct./08 17:22 ] |
| - Aucune alerte dans les logs |
[APP-22972] [laredoute] désactiver l'auto Création: 06/nov./08 10:13 Mise à jour: 24/nov./08 16:37 Résolue: 24/nov./08 12:46 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 35.0.0 (CTN-H) |
| Version(s) corrigée(s): | 35.0.0 (CTN-H) |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Swan Desportes | Attribution: | Damien Dorizy |
| Résolution: | Corrigé | ||
| Σ Estimation restante: | Non spécifié | Estimation restante: | Non spécifié |
| Σ Temps consacré: | Non spécifié | Temps consacré: | Non spécifié |
| Σ Estimation originale: | Non spécifié | Estimation originale: | Non spécifié |
| Pièces jointes: |
screenshot-1.jpg
screenshot-2.jpg
screenshot-3.jpg
|
||||||||||
| Sous-tâches: |
|
||||||||||
| Pays: |
FRA - France
|
||||||||||
| Projets PM: | *** CHASSE *** |
| Description |
|
Il faut désactiver l'auto de laredoute avec les configs et vérifier que ça fonctionne bien.
|
| Commentaires |
| Commentaire de Swan Desportes [ 06/nov./08 10:18 ] |
|
Mail d'Emeric : "Swan me disait la semaine dernière qu'on pouvait « simplement » désactiver cette partie. Je viens d'en discuter rapidement avec Alexandre et Clément et, à priori, il « suffirait » de : - Couper la partie business via la property dédiée - Supprimer la conf IG dédiée Cela reste apparemment de la théorie car on n'a jamais essayé... mais l'implication Dev serait relativement limitée (dans l'absolu, on peut même imaginer que le premier aspect soit géré par l'Exploit et le second par le Param, même si en général, ce sont les Devs qui gèrent la config IG). Ça, c'est pour l'option « brutale ». Après, si on souhaite gérer le travail en douceur, ça devrait être un peu plus laborieux... (et le mail du mec de LRO semble induire qu'il vaudrait mieux qu'on prenne des gants...) Pour moi, deux options : - On (qui ? Swan car CoB ou Bibi car Auto ?) fait une analyse plus poussée pour aider à la prise d'une décision OU - On teste directement en Integ pour voir ce qui se passe et en déduire, si besoin, les aspects à gérer plus en douceur.... " |
| Commentaire de Damien Dorizy [ 06/nov./08 18:17 ] |
|
Ok pour la config, elle est supprimée pour la redoute : cms1 default /CONFIG Voir pour l'espacement des onglets et si tout est ok dans mon compte, je laisse le Jira ouvert en attendant. |
| Commentaire de Ghislain Gridel [ 13/nov./08 14:39 ] |
|
attention à bien nous tenir au courant sur le planning de désactivation car cela a un impact sur : - le marketing - le BI - l'exploit. Merci. |
| Commentaire de Damien Dorizy [ 13/nov./08 16:20 ] |
|
Ghislain, La désactivation de la Redoute aura lieu le 25 novembre, lors de la mise en production de la CTN-H. |
| Commentaire de Ghislain Gridel [ 13/nov./08 16:28 ] |
| c'est un peu tôt. peut-on décaler vers le 15/12, pour nous laisser le temps d'envoyer l'email ? |
| Commentaire de Swan Desportes [ 13/nov./08 16:31 ] |
| Désolé Ghislain mais nous avons fait une réu avec EMT il y a plus de deux semaines pour dire que la deadline était fin novembre. |
| Commentaire de Ghislain Gridel [ 13/nov./08 16:47 ] |
|
ok. c'est un peu le rush du coup mais on va y arriver :-) |
| Commentaire de Aurélie Kwiatkowski [ 20/nov./08 16:19 ] |
|
Une trace de l'auto sur la page Vendre, c'est normal? L'onglet Vendre est un peu isolé, on ne peut pas le mettre avec les autres? |
| Commentaire de Aurélie Kwiatkowski [ 20/nov./08 16:21 ] |
|
En fait, le bloc se trouve sur la page Tous les Produits. Sur la page Vendre, il est toujours possible de vendre de l'Auto. |
| Commentaire de Damien Dorizy [ 20/nov./08 17:13 ] |
|
En effet, c'est un contenu en trop. Le voilà supprimé : cms1 /express/Article/Side Article/HP2007/Hp Left Auto - Via Michelin (261654) /express/Article/Side Article/HP2007/Hp Left Auto - La Redoute (261653) /express/Article/Side Article/HP2007/Hp Left Auto - Epik (261652) Merci |
| Commentaire de Olga Costa [ 20/nov./08 18:06 ] |
| Damien il faut aussi faire sur CMS3 |
| Commentaire de Damien Dorizy [ 20/nov./08 18:14 ] |
|
Va falloir renommer express alors ;) cms3 /express/Article/Side Article/HP2007/Hp Left Auto - Via Michelin (264009) /express/Article/Side Article/HP2007/Hp Left Auto - La Redoute (264008) /express/Article/Side Article/HP2007/Hp Left Auto - Epik (264007) Merci |
| Commentaire de Emeric Teil [ 20/nov./08 19:11 ] |
| Pour l'isolement de l'onglet "Vendre", on s'est posé la question : Justin à tranché en estimant que cela pourrait au contraire augmenter la visibilité de ce bouton et que ce n'était donc pas un mal. |
| Commentaire de Cédric Goldovsky [ 21/nov./08 16:52 ] |
| J'ai vu un lien dans le footer, cf capture. Certainement rien de grave et une manip qui m'échappe mais je signale quand même. |
| Commentaire de Emeric Teil [ 21/nov./08 17:04 ] |
| Bien vu Cedric, merci. Damien ? :o) |
| Commentaire de Damien Dorizy [ 21/nov./08 17:19 ] |
|
Bien ouéj. C'était en dur dans le footer. C'est supprimé. |
| Commentaire de Christophe Garcia [ 24/nov./08 11:01 ] |
| Encore sur la page Vendre |
| Commentaire de Damien Dorizy [ 24/nov./08 12:44 ] |
|
cms1 + cms3 /laredoute/Article/Vente/hp_vente Merci Olga |
[APP-23369] Rediriger BARGAIN vers quoi ? Création: 28/nov./08 11:28 Mise à jour: 08/janv./09 15:28 Résolue: 08/janv./09 12:10 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 38.0.0 (TX-D Bis) |
| Version(s) corrigée(s): | 38.0.0 (TX-D Bis) |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Christophe Garcia | Attribution: | Arnaud Forgues |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM: | *** RESERVE *** |
| Description |
|
Il reste une redirection vers de la NPC : celle de BARGAIN. Qu'en fait-on ? # Rewrite /bargain with tracking (manage url with cgi and path mode) # Compatibilité ancienne TG /bargain RewriteCond %{QUERY_STRING} ".*t=.*" [OR] RewriteCond %{QUERY_STRING} ".*tracking=.*" RewriteRule ^/bargain /navigation/default/category/bargain [R,L,QSA,NE] RewriteCond %{THE_REQUEST} "/bargain(.*)/t/(\S+)" RewriteRule ^/bargain /navigation/default/category/bargain%1/t/%2 [R,L,NE] RewriteCond %{THE_REQUEST} "/bargain(.*)/tracking/(\S+)" RewriteRule ^/bargain /navigation/default/category/bargain%1/tracking/%2 [R,L,NE] |
| Commentaires |
| Commentaire de Marion Anfreville [ 22/déc./08 17:47 ] |
|
Vu avec JEV : ce n'est pas de la NpC mais de la promo : http://bo.priceminister.com/category_back?action=categorysearch&javascript_callback=&category_id=&ctg_status_code=&category_label=&category_alias=&ctg_type_code=&ctp_type_code=&ctg_parameter_value=bargain&category_soft_alias=&start_date=&date_search_type=0&end_date=&number_rows=100&x=0&y=0 La page affiche de vieilles TG (06/06/2006) => TG gérées par les commerciaux. http://www.priceminister.com/navigation/default/category/bargain Est-ce que quelqu'un sait par où on accède à cette page sur le site ? |
| Commentaire de Thierry Leforestier [ 22/déc./08 17:59 ] |
| Vraisemblablement uniquement par le biais de Google. Il faut voir avec les commerciaux si ils l'utilisent toujours, si ce n'est pas le cas, rediriger en 301 vers la home Price. |
| Commentaire de Thierry Leforestier [ 06/janv./09 09:53 ] |
|
Pour le moment, nous n'avons pas trouvé a quoi pouvait
servir cette page... étant donné qu'elle n'est pas référencée par
Google, je vous laisse le soin de choisir vers ou elle sera redirigée. Thierry |
| Commentaire de Christophe Garcia [ 08/janv./09 11:33 ] |
| Alors ce sera la Home |
| Commentaire de Christophe Garcia [ 08/janv./09 12:00 ] |
|
Après vérification en PROD, il s'avère que cette page n'est
plus appelée (sauf en interne pour générer une page statique). Autant dire qu'au final, on fait sauter la redirection (et qu'on fera sauter la page statique) Nicolas, Merci de supprimer les lignes dans le rewrite.rules.fr |
| Commentaire de Arnaud Forgues [ 08/janv./09 12:10 ] |
|
OK ! Règles supprimées du fichier rewrite.rules.fr NB : -------------- This line and the following will be ignored -------------- modified: source/etc/apache/rewrite.rules.fr Committed revision 24944. [forguesa@gobillard source]$ bzr tag --force V38_0_0 Created tag V38_0_0. |
[IMP-3055] Le pro a importé son fichier ce matin pour les soldes > la pastille de réduction n'apparaît pas > maeva53 Création: 07/janv./09 12:30 Mise à jour: 30/oct./09 15:52 Résolue: 23/janv./09 11:46 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Bloquant |
| Rapporteur: | Isabelle Weisbecker | Attribution: | Fotigui Tangara |
| Résolution: | Aucune correction envisagée | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Login: | maeva53 |
| Séparateur: | N/A |
| Type de traitement: |
N/A
|
| Description |
|
Pourriez-vous vérifier que le pro ait bien mis 2 prix
différents dans les 2 colonnes de prix. Il me dit que oui. Sinon
pourriez-résoudre ce bug asap. exemple de produit où il devrait y avoir une pastille de réduction http://bo.priceminister.com/offer/buy/71476698/cpl73877986_ALL/Mini-Jupe-Carreaux-Ecossaise-Avec-Ceinture-Ultra-Sexy-Neuf-36-38-40-42-44-Sexy-Neuf-L-incontournable-De-La-Collection-Hiver-2008-2009-Expedie-En-24-48hrs.html |
| Commentaires |
| Commentaire de Fotigui Tangara [ 07/janv./09 13:56 ] |
|
Peux-tu me faire une extraction de son stock dans sa totalité ? |
| Commentaire de Isabelle Weisbecker [ 07/janv./09 15:35 ] |
| le BI ne fonctionne pas depuis hier. si tu pouvais récupérer le fichier importé par le pro ce matin et le repasser ce serait cool. |
| Commentaire de Fotigui Tangara [ 07/janv./09 17:27 ] |
|
le pro envoie une multitude de petits fichiers à chaque
fois, c'est pas évident de toucher un max de fiches produits/annonces en
même temps. soumettre de nouveau l'ensemble des fichiers qu'ils ont envoyé en la date d'aujourd'hui ? J'ai modifié leur profil pour qu'il tienne compte de maj de fiches produits.... |
| Commentaire de Fotigui Tangara [ 07/janv./09 17:28 ] |
| Je veux dire que le Pro doit soumettre de nouveau l'ensemble des fichiers qu'ils ont envoyé en la date d'aujourd'hui. |
| Commentaire de Isabelle Weisbecker [ 07/janv./09 18:14 ] |
| pas de bug pour la pastille de remise ? les prix etaient-ils identiques ou différents ? |
| Commentaire de Fotigui Tangara [ 08/janv./09 16:03 ] |
|
J'ai testé quelques fichiers (les fichiers envoyés entre le 6
et 7/01/09), il y a bien les prix d'origine et les prix de vente qui
sont différentes. Donc la pastille de remise devrait s'afficher avec le
bon taux de réduction. Mais si auparavant, certains fichiers ont été soumis sans "prix d'origine", la pastille ne s'affichera pas car le type de traitement appliqué ne permettait pas la mise à jour des fiches de produits. J'ai apporté une modification pour permettre la mise des fiches de produits, et cela depuis hier. C'est pour ces raisons que je préconisait qu'on fasse une extraction du stock du Pro, de filtrer les fiches de produits concernées, et de les traiter (les mettre à jour)..... |
| Commentaire de Fotigui Tangara [ 14/janv./09 13:48 ] |
| Avez-vous pu avoir une extraction de stock pour ce partenaire ? |
| Commentaire de Fotigui Tangara [ 20/janv./09 11:32 ] |
| Cette demande est-elle toujours d'actualité ? |
| Commentaire de Fotigui Tangara [ 23/janv./09 11:44 ] |
|
Je pense que je ferme cette demande pour laquelle je n'ai pas eu de retour. |
[APP-23967] ES - Affiliation : Ajout d'un tag sur la page d'activation vendeur Création: 13/janv./09 15:41 Mise à jour: 16/févr./09 17:45 Résolue: 16/févr./09 17:45 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 40.0.1 |
| Type: | Nouvelle fonctionnalité | Priorité: | Majeur |
| Rapporteur: | Charles Decaux | Attribution: | Rocio Perez-Garcia |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ESP - Espagne
|
| Projets PM: | *** A PLANIFIER *** |
| WishList: | Marketing |
| Classif FONC: | webanalytics |
| Description |
|
Hello, on va lancer un programme d'affiliation qui rémunère les affiliés qui génèrent des premières mises en vente. Il faut donc poser un tag sur la page d'activation vendeur. Ce tag ne doit apparaître que si le last tracking est t=1438040 ou t=1416040 Voici le tag à poser : <img src="http://tracking.publicidees.com/check.php?comid=107754&progid=902&uniqid=[NUMERO UNIQUE de l'ANNONCE]&price=&data=" width="0" height="0" border="0"> Plusieurs points aux quels il faut faire attention : - si la page est sécurisée, remplacer http par https - dans la variable uniqid, il faut mettre le numéro unique de l'annonce - il ne faut pas conserver les crochets Merci |
| Commentaires |
| Commentaire de Jérôme Viviès [ 19/janv./09 17:38 ] |
| Rocio, merci d'indiquer à Charles dans quel dump ça peut passer et quand ce sera en ligne, stp. |
| Commentaire de Rocio Perez-Garcia [ 22/janv./09 14:33 ] |
|
Salut Charles, le code tracking est paramétré en IG de façon qui reste 30 jours dans la cookie (comme en FR) Concernant le point de variable uniqid, les dev me confirment que ce n'est pas possible dans la page Activation Vendeur (car le membre peut ouvrir sa boutique avec 1 ou 100 annonces). Pour le tester il faut copier le code de activation boutique depuis le BO car les batch de mails ne tournent pas automatiquement en param et on perd Spot en chemin. Si tu veux plus de précision ou qqch ne va pas suis à ta disposition. |
| Commentaire de Rocio Perez-Garcia [ 23/janv./09 09:46 ] |
|
Charles, Olga me confirme que le tag peut passer mercredi prochain. Si c'est ok pour toi on le publie pour cette date. Merci |
| Commentaire de Charles Decaux [ 23/janv./09 17:02 ] |
|
Ok c'est bon pour moi, merci Rocio !!!! Faut-il que je teste quelque part ? |
| Commentaire de Rocio Perez-Garcia [ 23/janv./09 18:10 ] |
|
Oui, comme indiqué, tu peux tester en param2 ou avec spot.
Mais pour ne pas perdre le tracking ou devoir relancer l'envoi des
mails, tu dois recopier le code activation boutique de ton compte depuis
le BO. Alexandre Garnier et moi on a du tester comme ça et ça donne: <img src="urlblocker://http://tracking.publicidees.com/check.php?comid=107754&progid=902&uniqid=&price=&data=" width="0" height="0" border="0"> A+ |
| Commentaire de Charles Decaux [ 23/janv./09 18:16 ] |
|
Ok merci Rocio. Pourquoi y-a-t-il "urlblocker" au debut de l' URL ? |
| Commentaire de Alexandre Garnier [ 26/janv./09 09:51 ] |
|
urlblocker est un moyen d'éviter de pourrir les données avec les tests en DEV et INTEG. Ainsi, on écrit les tags mais les URL sont volontairement cassées pour ne pas envoyer les données aux partenaires. |
| Commentaire de Charles Decaux [ 03/févr./09 10:29 ] |
| Ok merci de ta réponse. Dans ce cas c'est bon pour moi, on peut passer en prod. |
| Commentaire de Rocio Perez-Garcia [ 04/févr./09 12:18 ] |
|
Salut, Charles m'a demandé hier si on pourrait mettre dans un tag de activation vendeur par « uniqid » la variable correspondante au identifiant vendeur. Je ne le trouve pas et Olga m'a dit que seulement userid pourrait être compatible avec ce tag. Vous pouvez me confirmer si existe la possibilité d'ajouter un identifiant ? Merci |
| Commentaire de Charles Decaux [ 04/févr./09 12:56 ] |
|
En fait, il faut juste regarder quelle variable a été passée
sur le tag affiliation en France sur l'événement seller activation
account et mettre exactement la même variable je pense. En effet,
derrière ce tag, il y a des dépendances avec des rapports BI, c'est donc
essentiel qu'on fasse exactement comme on a fait sur la France. Si le
userid a été utilisé sur la France, alors mettons le userid. Merci |
| Commentaire de Rocio Perez-Garcia [ 04/févr./09 16:58 ] |
|
Sur France il a: $user.UserAccountId. J'ajoute ce paramètre. A tester sur param2 merci |
| Commentaire de Charles Decaux [ 06/févr./09 09:52 ] |
|
Rocio, peux-tu me rappeler l'URL de param2 ? Merci ! |
| Commentaire de Rocio Perez-Garcia [ 06/févr./09 11:57 ] |
|
Bien sur: http://www.param2.pm.dev/info/home ou utiliser spot: http://bo.param2.pm.dev/spot_back |
| Commentaire de Rocio Perez-Garcia [ 09/févr./09 10:57 ] |
| En prod le 17/02. |
| Commentaire de Aurélie Kwiatkowski [ 16/févr./09 11:23 ] |
|
Rocio, J'ai testé en integ avec spot et je ne le trouve pas. Il concerne quel évènement? Je ne le trouve ni avec first_advert, ni avec seller_account activation. |
| Commentaire de Aurélie Kwiatkowski [ 16/févr./09 17:45 ] |
|
OK en integ <!--@@@ Plubiidees t=1438040-1416040 Seller_account_activation : Event - Seller account activation --> <img src="urlblocker://http://tracking.publicidees.com/check.php?comid=107754&progid=902&uniqid=16447193&price=&data=" width="0" height="0" border="0"> |
[IMP-3096] mettre le stock cosmétiques du pro à 0 > leadering Création: 15/janv./09 15:01 Mise à jour: 30/oct./09 15:53 Résolue: 16/janv./09 13:46 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Isabelle Weisbecker | Attribution: | Fotigui Tangara |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Advert_listing_by_login_parfum.csv
|
||||||||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Login: | leadering | ||||||||
| Séparateur: | N/A | ||||||||
| Type de traitement: |
Mise à jour/création annonces avec mise à jour/création produits (écrasement)
|
||||||||
| Description |
|
j'aurais voulu importer un fichier avec stock 0 pour
supprimer ses annonces mais le lien des imports a déjà été supprimé.
pouvez-vous juste supprimer les produits cosmétiques ? il y a plus de
10000 réf, difficile de les supprimer manuellement pour le pro.
|
| Commentaires |
| Commentaire de Isabelle Weisbecker [ 15/janv./09 16:58 ] |
| comme discuté, en pièce jointe l'export BI des parfums. merci. |
| Commentaire de Fotigui Tangara [ 16/janv./09 11:00 ] |
|
La suppression des annonces de type "COSMETIC" est en cours. Suivra cette action, une suppression radicale de toutes les fiches produits ayant servi à la création des annonces de type "COSMETIC". A suivre. |
| Commentaire de Cedric Favero [ 16/janv./09 11:05 ] |
| Super, merci. |
| Commentaire de Fotigui Tangara [ 16/janv./09 11:46 ] |
|
Toutes les annonces type "COSMETIC" sont mortes !!! Je m'attaque aux fiches produits maintenant :-) |
| Commentaire de Fotigui Tangara [ 16/janv./09 13:43 ] |
|
Toutes les fiches produits ont été supprimées, n'hésitez pas à vérifier et me dire si tout est OK. Demande traitée. |
| Commentaire de Aurélien Vergalli [ 16/janv./09 14:08 ] |
|
Je confirme, c'est OK. Merci. |
[BIN-542] [CRM achat] : vérification d'un rapport perso Création: 08/janv./09 17:27 Mise à jour: 23/mars/09 13:52 Résolue: 14/janv./09 19:56 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | CRM |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Thomas Beylot | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
hello dans le cadre des prev 2009 je m'apprête à me servir d'un rapport comme étant la clé de voûte de tous mes chiffres. Sous mon perso il s'appelle "nombre d'acheteurs (dont nouveaux) par mois". Pourriez vous me valider la bonne requête (c'est assez rapide, elle est très simple) pour que je sois sûr de bien faire les choses? grand merci ! |
| Commentaires |
| Commentaire de Agathe Remy [ 14/janv./09 19:56 ] |
|
Bonsoir Thomas, Ta requête semble juste : elle compte le nb d'acheteurs, dont nouveaux, ayant effectués au moins un panier autorisé par mois d'autorisation. Mais comme tu n'indiques pas l'objectif de ce rapport, c'est un pur d'en dire plus. Agathe |
| Commentaire de Agathe Remy [ 14/janv./09 20:04 ] |
|
Attention, dans ton rapport tu inclus les négociations et les paniers Automobile... Agathe |
| Commentaire de Thomas Beylot [ 15/janv./09 08:53 ] |
|
ok je vais aller voir comment retirer ça sinon en fait mon objectif est juste d'avoir un rapport pour lister le nb d'acheteurs et nouveaux par mois, histoire d'avoir des indicateurs pour faire mes prev et aussi me construire une sorte de scorecard fid. voilà. |
| Commentaire de Agathe Remy [ 16/janv./09 19:37 ] |
|
Pour information, la notion de 1er achat a été construite au
tout début du BI. En validant les données UK et forts de notre
expérience PriceMinistérienne, nous nous sommes aperçu que les règles de
gestion ne sont pas tout à fait juste. Après étude, je peux donc te garantir l'exactitude de l'information à 2% près. |
| Commentaire de Agathe Remy [ 16/janv./09 19:40 ] |
|
Oups, j'ai cliqué trop vite:-( Je continue : Nous avons intégré à notre roadmap 2009 la correction de cette information pour la rendre tout à fait exacte et nous te tiendrons au courant de l'intégration de cette correction. Agathe |
| Commentaire de Thomas Beylot [ 05/févr./09 10:56 ] |
|
ok merci de l'info me confirmes tu avant que je ne plonge dedans que je peux retirer les infos "auto" des rapports que je construis ? thomas |
[IMP-3133] Importer les prix d'origine = prix de vente > carthage51 Création: 22/janv./09 14:55 Mise à jour: 30/oct./09 15:52 Résolue: 22/janv./09 17:09 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Isabelle Weisbecker | Attribution: | Fotigui Tangara |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Copie de Advert_listing_by_login.csv
|
| Pays: |
FRA - France
|
| Login: | carthage51 |
| Séparateur: | Point-virgule (;) |
| Type de traitement: |
Mise à jour/création annonces avec mise à jour/création produits
|
| Description |
|
Importer uniquement les prix, pas les quantités. le pro
attend cet import pour pouvoir baisser ses prix et bénéficier de la
pastille de réduction.
|
| Commentaires |
| Commentaire de Fotigui Tangara [ 22/janv./09 15:07 ] |
|
Pour que la pastille de réduction s'affiche, il faut le prix
d'origine qui, comparé au prix de vente donne le pourcentage de
réduction. Dans le fichier en PJ, il manque le prix d'origine... |
| Commentaire de Isabelle Weisbecker [ 22/janv./09 15:36 ] |
|
euh comment te dire, justement il n'y en a pas dans le
fichier parcequ'il n'y en a pas sur le site. Je viens de faire un
extract BI. Peux-tu ajouter une colonne à l'endroit où il faut avec le même prix pour les 2 colonnes. |
| Commentaire de Fotigui Tangara [ 22/janv./09 15:59 ] |
|
oui, Je ferais la mise à jour des fiches de produits (car elles sont concernées par la maj du prix d'origine). Les prix d'origne seront égaux aux prix de vente, la pastille ne s'affichera pas, donc il va falloir passer un second fichier dont les prix de vente sont inférieurs au prix d'origine pour voir la pastille s'afficher... On fait comme ça ? |
| Commentaire de Fotigui Tangara [ 22/janv./09 16:42 ] |
| Demande en cours de traitement. |
| Commentaire de Fotigui Tangara [ 22/janv./09 17:07 ] |
|
Demande traitée. |
[BIN-552] Accès au Rapport BO : "Purchase by purchase tracking" pour Swan Desportes Création: 22/janv./09 14:20 Mise à jour: 11/mars/09 09:45 Résolue: 05/févr./09 17:43 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Swan Desportes | Attribution: | Dalila Belkebir |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Hello Je passe par JIRA pour vous demander accès un Rapport BO : "Purchase by purchase tracking" J'utilise un compte technique commun. Merci |
| Commentaires |
| Commentaire de Dalila Belkebir [ 22/janv./09 17:03 ] |
|
Bonjour Swan, Une refonte des accès est en cours et devrait être mise en production tout début de semaine prochaine. Je prendrai en compte ta demande lors de cette refonte. je te tiens au courant de la livraison des nouveaux droits. Cordialement, Dalila. |
| Commentaire de Dalila Belkebir [ 05/févr./09 17:43 ] |
|
Bonjour Swan, C'est livré en prod BI. Merci de ton retour sur le JIRA pour fermeture de la demande. Cdlt, Dalila. |
| Commentaire de Agathe Remy [ 17/févr./09 11:42 ] |
|
Bonjour Swan, Peux-tu valider ce JIRA afin que nous puissions le clôturer? Merci. Agathe |
| Commentaire de Agathe Remy [ 05/mars/09 16:00 ] |
|
Bonjour Swan, 3ème rappel!!! S'il te plait, peux-tu valider ce JIRA afin que nous puissions le clôturer? Merci. Agathe |
| Commentaire de Swan Desportes [ 11/mars/09 09:36 ] |
|
Merveilleux ! C'est bon Désolé pour cette réponse tardive. Merci |
[BIN-551] [Sales] : extraction de stock collectorliv Création: 21/janv./09 14:20 Mise à jour: 28/janv./09 20:05 Résolue: 22/janv./09 16:42 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Anne Korchia | Attribution: | Dalila Belkebir |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
export de stock collectorliv 210109.rar
|
| Pays: |
FRA - France
|
| Description |
|
extraction de stock collectorliv je n'arrive pas à le faire
le client est très mécontent car n'a pas les données qu'il avait rentré
au départ sur price à savoir auteur, éditeur année etc... Pouvez vous faire quelque chose ? |
| Commentaires |
| Commentaire de Dalila Belkebir [ 22/janv./09 16:42 ] |
|
Bonjour Anne, Je me suis connectée au BI. Dans Dossiers publics/ sales j'ai lancé le rapport "Advert listing by login " en mentionnant "collectorliv" comme login en invite. Le fichier généré est joint au JIRA. Si c'est OK pour toi, merci de me confirmer le JIRA pour clôture. dalila. |
| Commentaire de Anne Korchia [ 22/janv./09 16:56 ] |
|
je te remercie je pense que le fichier est correct je le renvoie au pro et on verra s'il a tout ce dont il a besoin merci |
[CAT-2502] Validation Welcome Process et Valorisation 1er achat Création: 28/janv./09 11:01 Mise à jour: 14/avr./10 09:14 Résolue: 14/avr./10 09:14 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Non Import |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Pierre-Emmanuel Bianchi | Attribution: | Rocio Perez-Garcia |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ESP - Espagne
|
| Description |
|
Rocío, tu m'avais fait savoir qu'il y avait quelques fautes
dans l'un des Welcome Process... Je t'envois donc les liens, pour que tu
puisses les checker. J'en profite également pour t'envoyer le lien du
Mailing Valorisation 1er achat, au cas où. Les WP : http://www.priceminister.es/newletter/welcome_process/wp01/wp01.html http://www.priceminister.es/newletter/welcome_process/wp02/wp02.html http://www.priceminister.es/newletter/welcome_process/wp03/wp03.html http://www.priceminister.es/newletter/welcome_process/wp04/wp04.html Valorisation 1er achat : http://www.priceminister.es/newletter/crm/2009-01-23-vpa/vpa.html Pour info, les BAT nous serons envoyés en fin de semaine, pour une mise en production prévue pour début février. Donc ça serait bien que tu puisses regarder ça aujourd'hui, afin que je puisse demander un dépannage aux graphistes s'il y a des choses à corriger. Merci beaucoup. |
| Commentaires |
| Commentaire de Rocio Perez-Garcia [ 28/janv./09 11:16 ] |
|
Avant de passer les corrections, j'ai une question: as tu
demandé la permission au membre chuqui11 pour mettre ce témoignage à son
nom? (on ne peut pas utiliser les pseudos sans permission...) Ou pourquoi n'as pas tu pris celui de Juan qui est plus réaliste? |
| Commentaire de Pierre-Emmanuel Bianchi [ 28/janv./09 11:20 ] |
| Oui j'ai la permission de chuqui11 (c'est Charles jeje). Donc il n'y a pas de problème!!! |
| Commentaire de Rocio Perez-Garcia [ 28/janv./09 11:42 ] |
|
Vale, tu me confirmes alors que dans le dernier Wp les témoignages sont validés par les utilisateurs? Merci |
| Commentaire de Rocio Perez-Garcia [ 28/janv./09 12:07 ] |
|
Salut Manu, voici les corrections: 1er WP Hola [[pseudo]], ¿Millones de productos nuevos y de segunda mano, vendidos tanto por particulares como por profesionales a precios de risa? ¡Eso es lo que te propone PriceMinister! Entonces ¡déjate seducir por el concepto, y descubre ya las ventajas de la compra-venta en Internet! Ir a PriceMinister ------------- 2ème WP Comprador o vendedor, PriceMinister quiere hacerte feliz. ¡Déjanos enseñarte nuestras ventajas! ----- 4ème WP Alguien me dijo que: Pas d'exclamations, nous ne l'utilisons presque pas, en dans ces phrases sont inutiles. Además, los precios son muy económicos => es grass n'avons pas besoin de ¡!No se puede pedir más. ¡Estoy muy satisfecha!" --Ce temoignage n'est ni espagnol ni latinoamericain... "He llegado hace poco a España y me he dado cuenta de que PriceMinister era una buena opción para ganar dinero rápidamente. Puse mis anuncios y desde hace algunos meses, ¡ya he ganado más de 400 ¿! ¡Es genial,la verdad! Además, poner en venta es gratis. Muchas gracias a todo el equipo PriceMinister." --- News ok |
| Commentaire de Rocio Perez-Garcia [ 29/janv./09 15:59 ] |
| Validation edito |
| Commentaire de Nerea Prieto [ 30/sept./09 16:50 ] |
|
Bonjour, Après tout ce qu'on s'est dit sur le mot "Listillo", je crois qu'il faudrait le remplacer, je propose aux espagnols de donner ses idées et après on vote la meilleur. Voici les miennes: - Astuto - Avispado - Espabilado |
| Commentaire de Pierre-Emmanuel Bianchi [ 02/oct./09 18:18 ] |
| Et "gorrón"? |
| Commentaire de Rocio Perez-Garcia [ 05/oct./09 11:41 ] |
|
Gorrón es encore plus péjoratif que Listillo. Je propose : Ya has llegado al club de los que saben comprar o comme dit Nerea, Bienvenido al club de los compradores astutos / espabilados / avispados (dans cet ordre de préférence) |
| Commentaire de Rocio Perez-Garcia [ 12/oct./09 17:25 ] |
| Il reste que Juan nos donne sa proposition et que Pierre-Emmanuel confirme le wording. |
| Commentaire de Juan Luis Fajardo [ 12/oct./09 17:35 ] |
|
Ma proposition: ----------------------------------------- 1er WP Hola [[pseudo]], Priceminister te propone millones de productos nuevos y de segunda mano, vendidos tanto por particulares como por profesionales a precios de risa. ¡Déjate seducir por nuestro concepto, y descubre ya las ventajas de la compra-venta en Internet! Ir a PriceMinister ------------- 2ème WP Comprador o vendedor, PriceMinister quiere hacerte feliz. ¡Déjanos enseñarte nuestras ventajas! ----- 4ème WP Temoignage: "He llegado hace poco a España y me he dado cuenta de que PriceMinister era una buena opción para ganar dinero rápidamente. Puse mis anuncios y en pocos meses ya he ganado más de 400 euros ¡Es genial,la verdad! Además, poner en venta es gratis. Muchas gracias a todo el equipo PriceMinister." ------- à la place de "listillo" o "gorrón", je préfère "comprador astuto" |
| Commentaire de Pierre-Emmanuel Bianchi [ 12/oct./09 17:57 ] |
|
Je suis d'accord avec Juan Luis pour les WP 1, 2 et 4. Concernant le mail Valorisation 1er achat, j'opterais pour un mix Nerea / Rocio. Ça donne: Ya has llegado al club de los compradores astutos On est tous d'accord sur le wording? Je peux demander à 1000Mercis de faire les modifs? (si ils ne peuvent pas le faire, je réserverai du temps graphiste). |
| Commentaire de Rocio Perez-Garcia [ 13/oct./09 11:49 ] |
|
Ok pour moi. Dis moi si tu vas nos présenter les maquettes par le biais de ce jira ou je peux le fermer. merci ! |
| Commentaire de Pierre-Emmanuel Bianchi [ 13/oct./09 11:54 ] |
|
Effectivement, je pense que ça passera par ce JIRA. Il est donc préférable de le laisser ouvert. Merci. |
| Commentaire de Cantoni Carlos [ 23/oct./09 09:27 ] |
|
des nouvelles par rapport a ce Jira? j'ai reçu hier un mail avec l'objet "eldiscoloco1, ¡Qué listillo eres! ¡Has descubierto el mejor Mercado de la Web!" |
| Commentaire de Rocio Perez-Garcia [ 18/déc./09 14:28 ] |
|
Salut Pierre- Emmanuel, des nouvelles sur ce Jira ? Une autre chose que je voulais te commenter : Plusieurs personnes avec une compte en PMES m'ont fait savoir qui ne reçoivent pas ni les news ni les CRM. Est-ce que tu peux te renseigner si la base de Mille mercis est à jour? ( en sachant que ils ont ouvert son compte à l'ouverture de PMES et qui font des achats c'est un peu bizarre). Merci!! |
| Commentaire de Pierre-Emmanuel Bianchi [ 18/déc./09 14:57 ] |
|
Salut Rocio :) Pour les modifs éditos des mails automatisés, je m'en occuperai prochainement. Il faut que je réserve du temps graphiste, mais pour l'instant c'est un peu full. Concernant ces personnes qui ne reçoivent pas les mails, je vais en parler à 1000mercis. Merci, P-E |
| Commentaire de Cantoni Carlos [ 05/mars/10 11:49 ] |
|
des nouvelles par rapport a ce Jira? j'ai reçu hier un mail aujourd'hui avec l'objet "eldiscoloco1, ¡Qué listillo eres! ¡Has descubierto el mejor Mercado de la Web!" de plus, il y a des liens qui ne marchent pas car nous avons fait des changements dans les filtres exemple cd nuevos a menos de 3¿ = Tu búsqueda no da ningún resultado. |
| Commentaire de Pierre-Emmanuel Bianchi [ 05/mars/10 11:54 ] |
|
Bonjour à tous, Étant donné le passage de 1000mercis à e-circle, tous les CRM automatisés vont -a priori- être momentanément interrompus. Cela nous permettra donc de faire toutes les modifs éditos et techniques (redirects) nécessaires. Je vais réserver du temps graphiste, et vous tiens au courant. Je mettrai dans ce JIRA les maquettes des nouvelles versions dès qu'elles sont prêtes. Merci, P-E |
| Commentaire de Many Pes [ 08/mars/10 11:14 ] |
|
Pour l'URL qui n'est pas redirigée: CD nuevos por menos 3 euros: On a ceci: http://es.newsletter-priceminister.com/_c.aspx?i=12834&m=63&ue=21016811&r=46 Qui redirige en 302 vers: http://www.priceminister.es/nav/Musica_CD/fp/NDe+1+a+3+%26euro%3B/ft/n?t=1474040 Or il y a une erreur dans l'URL: il y a un N devant le "De+1..." à la place du A (fp/ADe+1+...) C'est pour ça que la redirection 301 ne fonctionne pas. Si on teste cette URL: http://www.priceminister.es/nav/Musica_CD/fp/ADe+1+a+3+%26euro%3B/ft/n?t=1474040 La redirection 301 fonctionne bien. |
| Commentaire de Pierre-Emmanuel Bianchi [ 13/avr./10 18:39 ] |
|
Bonjour à tous, Je travaille actuellement sur le brief de refonte de ces mails (changement des redirects ne fonctionnant plus, correction édito, etc.). Il sera en PJ avant la fin de la semaine. Mohamed effectuera quant à lui tous ces changements les 4 et 5 mai prochains. Merci, P-E |
| Commentaire de Rocio Perez-Garcia [ 14/avr./10 09:14 ] |
| Merci d'ouvrir une nouvelle demande pour la modification et corrections des nouveaux CRM. |
[IMP-3338] exctract de stock : lhankor_mhy Création: 02/mars/09 10:40 Mise à jour: 30/oct./09 15:43 Résolue: 02/mars/09 11:07 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Anne Korchia | Attribution: | Frédéric Nahum |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Login: | lhankor_mhy |
| Séparateur: | N/A |
| Type de traitement: |
N/A
|
| Description |
|
extraction de stock
|
| Commentaires |
| Commentaire de Frédéric Nahum [ 02/mars/09 11:07 ] |
| Les imports ne font plus d'extraction de stock, ils ont fait directement par les commerciaux via l'outil BI |
[BIN-560] [Marketing] : Vérification du rapport PMEV Last tracking Création: 23/févr./09 15:59 Mise à jour: 22/sept./09 10:29 Résolue: 22/sept./09 10:29 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Ghislain Gridel | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
BRIEF RAPPORT SUR LA VENTE.doc
BRIEF RAPPORT SUR LA VENTEv2.doc
DMR - Rapport PriceMinister -
Advert followup by tracking and product family v1.1.docx
|
||||||||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Description |
|
Bonjour Agathe, nos tableaux de reporting évoluent et de nouveaux KPI s'ajoutent régulièrement. Nous aimerions suivre l'indicateur Première Mise en Vente (PMEV) en last tracking par canal d'acquisition. Pour l'instant le critère 30 jours n'existe pas appremment. Peux-tu vérifier que les informations contenues dans ce rapport sont les bonnes stp ? Merci ! Favori > Ghislain > page 2 > New Seller par tracking pas à 30 jours A ta dispo pour toute question. Ghislain |
| Commentaires |
| Commentaire de Agathe Remy [ 23/févr./09 19:40 ] |
|
Bonjour Ghislain, D'après ce que j'ai compris des précédents échanges de mails, cet indicateur doit servir à des arbitrages budgétaires. Je pense donc qu'il est important de passer par un process BI de qualification de l'information fournie pour être sûr que ce soit la bonne, c'est à dire ne pas se contenter d'une simple "validation d'un rapport perso", mais par le développement d'un rapport public. En effet, la validation du rapport perso ne peut avoir qu'une valeur ponctuelle au moment de la-dite validation puisque vous pouvez modifiez ultérieurement le rapport et induire de potentielles erreurs. D'autre part, comme nous n'avons pas la maîtrise de ces rapports, nous n'y reportons pas les évolutions du site, induisant également de potentielles erreurs. Je pense également qu'il serait intéressant d'impliquer Thomas afin que, même si vous gérez des budgets et partenaires distincts, vous parliez le même langage et ayez conscience des éventuelles différences de stratégies induites par vos objectifs. Nous te proposons donc de développer un rapport BI qui sera livré dans l'arborescence "Dossiers publics" en respectant le process spécifications, développement, validation et livraison. Ce développement a d'ailleurs été priorisé par Odile pour début Q2 si vous nous livrez un brief avant fin mars. Pour info, à ma connaissance, il est tout à fait possible aujourd'hui de compter les premières mises en vente effectuées dans les 30 jours après le dépôt du coockie par le partenaire. A ta dispo pour en discuter. Agathe |
| Commentaire de Ghislain Gridel [ 27/févr./09 17:30 ] |
|
Merci Agathe. Bien noté. Je vous laisse développer ce rapport. Tant mieux si le last tracking 30 jours existe. De quel éléments supplémentaires as-tu besoin ? |
| Commentaire de Ghislain Gridel [ 04/mars/09 09:22 ] |
| le brief est ci-joint. A ta dispo pour toute question. |
| Commentaire de Ghislain Gridel [ 06/mars/09 12:30 ] |
| Une modification dans le brief, si possible il faudrait rajouter aussi la possibilité de pouvoir avoir ces chiffres sur le trafic spontané |
| Commentaire de Ghislain Gridel [ 06/mars/09 16:30 ] |
| par spontané j'entends "le reste du monde" |
| Commentaire de Agathe Remy [ 14/mai/09 17:00 ] |
|
Voici le rapport initial qu'il s'agit de faire évoluer. Agathe |
| Commentaire de Dalila Belkebir [ 29/mai/09 14:45 ] |
|
Bonjour Ghislain, Comme validé, je joins les spécifications que j'ai rédigées pour la demande. Les développements peuvent débuter. Je te tiens au courant de la mise à disposition des rapports spécifiés. Cdlt, Dalila. |
| Commentaire de Dalila Belkebir [ 12/juin/09 17:32 ] |
|
Bonjour, Dans le répertoire ADVERT, les anciens rapports Advert followup by tracking et Advert followup by tracking and product type qui n'étaient pas utilisés ont été supprimés et refondus en 2 nouveaux rapports : ¿ Monthly advert followup by tracking and product family Ce rapport a pour objectif le suivi de la mise en vente et du nombre de vendeurs dont nouveaux, par mois d'activité, groupe de tracking et famille de produit. ¿ Daily advert followup by tracking and product family Ce rapport a pour objectif le suivi de la mise en vente et du nombre de vendeurs dont nouveaux, par jour d'activité, groupe de tracking et famille de produit. Ces modifications ont eu lieu sur les plateformes France, UK & ESPAGNE. Merci de vos retours. Cdlt, Dalila. |
| Commentaire de Ghislain Gridel [ 15/juin/09 18:55 ] |
| merci ! |
| Commentaire de Agathe Remy [ 17/août/09 15:39 ] |
|
Bonjour Thomas, S'il te plait, peux-tu également valider ces rapports ? Merci. Agathe |
| Commentaire de Thomas Beylot [ 17/août/09 15:41 ] |
|
hello validation itou tu peux closer le jira :) |
| Commentaire de Agathe Remy [ 17/août/09 15:42 ] |
| Merci! |
| Commentaire de Ghislain Gridel [ 18/août/09 10:49 ] |
|
hello, les modifications demandées à la réunion de présentation du rapport n'ont pas été faites. ce jira ne peut donc pas être clôturé. |
| Commentaire de Dalila Belkebir [ 18/sept./09 10:39 ] |
|
Bonjour Ghislain, Les éléments remontés lors de la réunion de présentation sont des éléments d'évolution du rapport qui a été développé conformément aux spécifications validées. Je te propose donc de clôturer ce JIRA et de m'en créer un autre en y mentionnant les évolutions remontées lors de la réunion. Voici les retours que j'ai notés : - supprimer la colonne New seller count, redondante avec First advert count - supprimer la section sur la date -supprimer la rupture sur le tracking name pour l'afficher sur toutes les lignes de la colonne Est-ce bien cela ? Ces modifications interviennent essentiellement au niveau de la mise en forme afin de vous faciliter le retraitement des données dans excel. Aussi, si tu me fais ce JIRA assez rapidement je pourrais le traiter afin de clôturer le sujet. Cdlt, dalila. |
| Commentaire de Ghislain Gridel [ 21/sept./09 12:16 ] |
| http://pricejira.lan/browse/BIN-628 |
| Commentaire de Dalila Belkebir [ 22/sept./09 10:29 ] |
|
Ghislain, merci de ton retour. Je clôture la demande. les évolutions demandées seront donc traitées dans le JIRA http://pricejira.lan/browse/BIN-628 cdlt, dalila. |
[APP-24658] Configuration Page Dédiée Jeux concours films HUMAINS Création: 17/mars/09 10:06 Mise à jour: 02/avr./09 10:01 Résolue: 26/mars/09 10:29 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Infoglue, Promo |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 43.0.3 |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Charlotte Fachan | Attribution: | Carole Boucheny |
| Résolution: | Corrigé | ||
| Σ Estimation restante: | Non spécifié | Estimation restante: | Non spécifié |
| Σ Temps consacré: | Non spécifié | Temps consacré: | Non spécifié |
| Σ Estimation originale: | Non spécifié | Estimation originale: | Non spécifié |
| Sous-tâches: |
|
||||||||||||||||||||
| Pays: |
FRA - France
|
||||||||||||||||||||
| Projets PM: | *** RESERVE *** | ||||||||||||||||||||
| Classif FONC: | comarket |
| Commentaires |
| Commentaire de Charlotte Fachan [ 17/mars/09 10:25 ] |
|
Il faudrait prevoir la mise en ligne d'une page dédiée
Infoglue faisant la promotion de la sortie du Film Humains du 1/04/09 au
30/04/09. Quand doit-on vous fournir les éléments pour une mise en prod le 01/04 ? Merci Charlotte |
| Commentaire de Marion Anfreville [ 18/mars/09 11:51 ] |
| Nous avons besoin des éléments vendredi soir (20/03) pour qu'on puisse paramétrer/tester S13 et mettre en prod S14 (Dump 31/03 pour activation le 01/04). |
| Commentaire de Charlotte Fachan [ 20/mars/09 18:32 ] |
|
Comme convenu, les éléments relatifs à la page dédiée HUMAINS ont été déposées dans Infoglue. http://bo.test-fr.pm.dev/info/no/op/humains Nicolas doit encore faire quelques modifs lundi matin en arrivant. A votre dispo pour en parler Très bon week end Charlotte |
| Commentaire de Charlotte Fachan [ 23/mars/09 10:06 ] |
|
Tout est ok pour les éléments transmis. les dernières modifs ont été faites. merci Charlotte |
| Commentaire de Carole Boucheny [ 24/mars/09 12:00 ] |
|
Fait sur cms1. promotions/Direct Article/Opérations Marketing/humains Testable ici : http://bo.ref-fr.pm.dev/info/no/op/humains. Pouvez-vous valider ?? Merci |
| Commentaire de Charlotte Fachan [ 24/mars/09 12:10 ] |
|
ok pour moi ! merci Charlotte |
| Commentaire de Carole Boucheny [ 24/mars/09 16:03 ] |
|
Olga, Peux-tu mettre une version et valider ? Merci |
| Commentaire de Olga Costa [ 25/mars/09 10:53 ] |
|
J'ai testé la page, ok pour moi Par contre une question comment accède-t-on à cette page ? (une banner promos ? un lien ?) Merci |
| Commentaire de Charlotte Fachan [ 25/mars/09 11:45 ] |
|
Par le biais de bannières promo mises en place via ID REGIE. Charlotte |
[BIN-568] [BACK-OFFICE] optimisation requete evenements USER Création: 10/mars/09 16:30 Mise à jour: 06/avr./09 19:56 Résolue: 19/mars/09 10:40 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | BackOffice |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Cedric Favero | Attribution: | Julien Girardet |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
J'ai une requete qui apparemment fait planter la base :-( Malheureusement je suis amené à en avoir besoin souvent et celà meriterait donc optimisation. Il s'agit d'une requete recherchant tous les comptes ayant eu un evenement Login pour une IP donnée. A votre dispo pour plus d'informations. |
| Commentaires |
| Commentaire de Agathe Remy [ 10/mars/09 16:37 ] |
|
Cédric, S'il te plait, peux-tu préciser le nom et l'emplacement du rapport afin que nous récupérions la requête? Merci. Agathe |
| Commentaire de Cedric Favero [ 10/mars/09 16:42 ] |
| C'est chez moi , je partage pas mes requetes perso :-) |
| Commentaire de Cedric Favero [ 10/mars/09 16:43 ] |
| C'est "Recherche_connexions_par_IP" dans Dossiers Publics/ France / BO Working |
| Commentaire de Julien Girardet [ 19/mars/09 10:40 ] |
|
Bonjour Cedric, Les dernieres optimisations livrées dans le cadre du projet BI Abonnement, améliorent les performances de ton rapport "Recherche_connexions_par_IP" . Il s'execute en 5/6 min. Peux tu valider de ton coté ? Merci Julien. |
| Commentaire de Cedric Favero [ 19/mars/09 13:01 ] |
|
Ca marche du tonnerre! Merci. |
[BIN-592] [Sales] : Ajout des objets "libération accès adresse email" et "libération accès du numéro de téléphone acheteur" Création: 11/juin/09 11:23 Mise à jour: 03/juil./09 10:00 |
|
| Etat: | Bloqué |
| Projet: | Business Intelligence |
| Composants: | BackOffice |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Gaël Seguillon | Attribution: | Agathe Remy |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
GBR - Royaume Uni, FRA - France, ESP - Espagne
|
| Description |
|
Ce rapport consisterait à donner un reporting mensuel des
comptes ayant les droits libérés sur l'accès au téléphone et/ou à
l'email de leurs acheteurs. Aujourd'hui cette donnée ne figure pas le profil User. Les données nécessaires du rapport sont le pseudo, le type de compte (pro/part), le gestionnaire de compte, l'info sur 2 colonnes droits libérés email (O/N) droit libérés téléphone (O/N). Ce rapport ne doit lister que les comptes dont au moins un de ces deux droits est débloqués merci Gaël |
| Commentaires |
| Commentaire de Gaël Seguillon [ 17/juin/09 11:23 ] |
| ajouter cette donnée dans univers Item |
| Commentaire de Agathe Remy [ 02/juil./09 19:56 ] |
|
Bonsoir Gaël, Lors du développement, nous nous sommes aperçu que ces informations étaient mal alimentées dans le BI. Nous sommes donc dans l'incapacité de te les mettre à disposition sans faire évoluer l'alimentation. Nous te proposons donc d'ajouter cette évolution dans le prochain projet qui fera évoluer l'alimentation d'un compte utilisateur. Nous reviendrons vers toi lorsque nous aurons des infos sur un tel projet. Agathe |
| Commentaire de Agathe Remy [ 02/juil./09 19:59 ] |
|
Nous ne pouvons donc pas mettre en place de rapport de suivi. En revanche, si ton besoin est ponctuel et urgent, nous pouvons te proposer de réaliser un étude ponctuelle. A ta dispo si tu as des questions Agathe |
| Commentaire de Gaël Seguillon [ 03/juil./09 10:00 ] |
|
Bonjour je serai preneur de la liste des pros sur FR ES UK qui ont l'accés aux emailset/ou ou tél des acheteurs par avance merci |
[APP-25517] [Extension de garantie] suppression de trois tables plus utilisées Création: 08/juin/09 11:47 Mise à jour: 26/janv./10 14:33 Résolue: 25/janv./10 13:51 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 49.0.0 (TX-H) |
| Version(s) corrigée(s): | 60.0.0 (TX-L) |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Clement Balay | Attribution: | Marc-Antoine Decreton |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM: | *** CHASSE *** |
| Description |
|
Dans ce projet, nous avons crée trois nouvelles tables dans
un nouveau schéma (config_1) et laissé les trois tables existantes pour
ne pas gêner les devs. en version N+2, nous pouvons supprimer ces tables vu que toutes les branches sont mises à jour. Il s'agissait des tables: COMMISSION, COMMISSION_RULE et CMR_TYPE_CODE dans le schéma user_1. |
| Commentaires |
| Commentaire de Clement Balay [ 23/oct./09 12:20 ] |
| CAJ2009Q4TX |
| Commentaire de Clement Balay [ 23/oct./09 12:21 ] |
| Jira corrigé en TX-K, mais version pas dans jira encore |
| Commentaire de Christophe Garcia [ 23/oct./09 15:12 ] |
| MDPLVC |
| Commentaire de Clement Balay [ 23/oct./09 15:19 ] |
| En fait il me faudrait la version TX-K svp |
| Commentaire de Christophe Garcia [ 23/oct./09 16:55 ] |
| Tu l'as. |
| Commentaire de Clement Balay [ 23/oct./09 16:59 ] |
| Merci |
| Commentaire de Clement Balay [ 17/nov./09 10:17 ] |
| On le fera passer en TX-Q pour plus de sureté |
| Commentaire de Christophe Garcia [ 17/nov./09 10:32 ] |
| Tu veux que j'ajoute des lettres à l'alphabet ? |
| Commentaire de Christophe Garcia [ 17/nov./09 10:32 ] |
| MDPLVC |
| Commentaire de Clement Balay [ 17/nov./09 10:35 ] |
|
Tant qu'à faire, si tu pouvais monter jusqu'à Z, pour la suite on prendra peut-être les lettres de l'alphabet grec |
| Commentaire de Arnaud Forgues [ 25/janv./10 13:51 ] |
|
En fait, ce nettoyage a été fait en TX-L : - en DEV : OK - en INTEG : OK (mais il y a eu une copie de la PROD sur l'integ ensuite ....) - en PROD : NOK --> géré par PPE / BI |
[BIN-585] [Marketing Acquisition] : Rapport commission autorisée Création: 26/mai/09 14:51 Mise à jour: 28/janv./10 12:28 Résolue: 07/oct./09 18:00 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Ghislain Gridel | Attribution: | Julien Girardet |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
DMR - Rapport Daily item
followup by tracking and product family v1.0.docx
Maquette.xls
|
| Pays: |
FRA - France
|
| Description |
|
Hello, dans le cadre du suivi des campagnes de liens sponsorisés, nous aurions besoin d'un rapport qui nous donne la commission autorisée à 30 jours, par groupe et par code de tracking. Est-ce possible ? Merci. Ghislain |
| Commentaires |
| Commentaire de Agathe Remy [ 26/mai/09 19:33 ] |
|
Bien sûr que c'est possible! Pour étudier ta demande, il faudrait nous faire un brief avec : - le contexte du besoin - l'objectif principal du rapport - le mode d'utilisation (ponctuel, quotidien, hebdo, mensuel, etc...) - les critères de sélection (période de mois, groupe de tracking, etc...) - une maquette Merci. Agathe |
| Commentaire de Ghislain Gridel [ 29/mai/09 15:06 ] |
|
hello, Contexte Nous avons décidé de ne pas envoyer d'informations capturées à notre agence de liens sponsorisés car trop coûteux en temps technique. Nous leur enverrons uniquement les informations capturées. Par conséquent, nous envisageons de modifier la rémunération de l'agence. Leur rémunération actuelle est composée d'une partie fixe qui se déclenche par palier en fonction du budget investi; et composée d'une partie variable qui se déclenche à partir de palier de ROI calculé sur la commission capturée. Comme ils ne disposeront d'aucune information capturée pour optimiser les campagnes, nous ne pouvons pas les rémunérer sur la commission capturée en ce qui concerne la 2ème partie de la rémunération. Nous souhaiterions donc les rémunérer sur la commission autorisée. Hors aujourd'hui nous ne disposons pas d'informations relative à la commission autorisée. Objectif Suivre les le taux de perte entre le va / commission autorisée et le va / commission capturée par campagne et par sous-catégorie (ex CD). L'idée est de voir si cette perte augmente/baisse afin de mieux comprendre pourquoi le résultat net des campagnes pourrait augmenter/baisser. On entend par résultat net la différence entre les coûts (CPC payé à Google + rémunération Keyade) et la commission PM. Utilisation Quotidienne et mensuelle critère de sélection période de mois, période de jour (l'un et l'autre à choisir en fonction du besoin), groupe de tracking, code de tracking, catégorie, sous-catégorie. Le VA autorisé doit être le même que dans le rapport Purchase tracking by month (avec frais de port, avec CBV) et la commission doit inclure le CBV. A voir si on crée une colonne CBV à part ? Maquette Mois | groupe de tracking | code de tracking | catégorie | sous-catégorie | VA Autorisé | VA capturé | Commission autorisée | Commission capturée A votre dispo Ghislain |
| Commentaire de Julien Girardet [ 21/sept./09 11:49 ] |
|
Bonjour Ghislain, Voici la maquette du rapport fait à partir de ton brief. Quelques explications : Critères de sélection : - periode de jour d'autorisation - un ou plusieurs groupe de tracking - une ou plusieurs famille de produit Le rapport est par jour, groupe de tracking, tracking, famille de produit et type de produit Il n'y a pas de rupture et de section, donc pas de sous totaux Le rapport est en tracking 30 jours Le GMS (autorisé et capturé) inclut les frais de port et les garanties Les commissions sont détaillées par : article, frais de port, garanties Enfin, il y a aura un écart sur le VA autorisé avec les tableaux de bords MKT (Monthly purchase overview (30 days tracking)/ Weekly purchase overview (30 days tracking)) Ces rapports se base sur Purchase alors que ce nouveau rapport se base sur l'univers Item (car on veut la commission autorisée) Or il y a deux causes d'écart avec les rapports se basant sur Purchase : Panier en confirmation Denied : Ce sont des paniers autorisés mais dont les articles ont été supprimés par batch (autorisation de paiement refusée, panier vidé par le systeme) Ainsi le VA autorise calculé niveau ITEM ne prend pas en compte ces articles supprimés. Le recalcul des frais de ports mutualisés : Ce sont les paniers autorisés contenant plusieurs articles chez un-même vendeur dont au moins un article a été annulé. Ainsi le VA autorisé calculé niveau ITEM prend en compte le recalcul en fonction du nombre d'articles annulés chez un même vendeur. (=> voir JIRA BIN 584 [Keyade] : Etude évolution autorisé/capturé) Es tu dispo demain pour en discuter ? Julien. |
| Commentaire de Julien Girardet [ 23/sept./09 11:15 ] |
|
Bonjour Ghislain, Ci joint la specification du rapport. Peux tu la valider ? Suite à ta validation, nous commencerons le developpement du rapport. Merci Julien. |
| Commentaire de Ghislain Gridel [ 23/sept./09 11:54 ] |
| ok pour moi. Merci. |
| Commentaire de Dalila Belkebir [ 07/oct./09 18:00 ] |
|
Bonjour Ghislain, Nous venons de livrer le rapport après validation. Il est dans le répertoire PUBLIC / ITEM Daily item follow up by purchase tracking and product family Merci de ta validation pour clôture du JIRA. Cdlt, Dalila. |
| Commentaire de Dalila Belkebir [ 28/janv./10 12:28 ] |
|
Odile, Comme vu en point MKT BI du 18/01, cette demande est OK pour vous. Cdlt, Dalila. |
[BIN-619] Ajout dimension correspondant au RawListCaption Création: 27/juil./09 17:51 Mise à jour: 31/juil./09 12:34 Résolue: 31/juil./09 12:34 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | BackOffice |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Habib-Sylvain Gourguet | Attribution: | Agathe Remy |
| Résolution: | Invalid | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Description |
|
Pour une meilleure gestion des articles revendus sur
"retourpm", nous aurions besoin du RawListCaption dans "Product", pour
les univers "ITEM" et "ADVERT".
|
| Commentaires |
| Commentaire de Agathe Remy [ 31/juil./09 12:34 ] |
|
Désolée, mais le RawListCaption n'est pas un champ base de
données, mais une information fournie par le moteur de recherche:-( Nous sommes donc aujourd'hui incapable de fournir cette info dans BI. Agathe |
[BIN-600] [Compta] : Génération de l'historique du rapport "buyer refund" sur la France - 2007 - 2008 - 2009 Création: 30/juin/09 11:31 Mise à jour: 01/oct./09 11:38 Résolue: 17/juil./09 16:39 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Finance |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Bloquant |
| Rapporteur: | Claudie Dufresne | Attribution: | Julien Girardet |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Agathe, Dalila, Comme vu ensemble, les rapports "buyer refund by claim closing month" pour les années 2007,2008 et 2009 sont trop volumineux pour être édités, année par année, en un seul fichier. Nous avons besoin d'éditer ces fichiers tous les mois le jour où les opérations du mois précédent sont stabilisées. Est-il donc possible pour vous de prévoir une édition programmée de ces fichiers (un fichier par année) tous les mois (le jour de stabilisation des opérations de M-1)et dès la stabilisation des opérations du mois de juin ? merci par avance pour votre aide claudie |
| Commentaires |
| Commentaire de Julien Girardet [ 07/juil./09 16:46 ] |
|
Claudie, Aujourd'hui les chiffres sont stabilisés, j'ai donc généré les données "buyer refund" Je vais pouvoir créer les rapports d'historique. Sinon, Il existe 2 rapports sur les remboursements acheteurs : - Buyer refund by claim closing month : Ce rapport a pour objectif de fournir le détail de toutes les opérations de remboursement acheteur par article pour une période de clôture de réclamation. - Buyer refund without claim by completion month : Ce rapport a pour objectif de fournir le détail de toutes les opérations de remboursement acheteur pour les articles sans réclamation pour une période de finalisation des opérations. As tu besoin de l'historique du second rapport "Buyer refund without claim by completion month " pour la réconciliation ? Puisque qu'il ne traite pas des réclamations ... Julien. |
| Commentaire de Claudie Dufresne [ 07/juil./09 18:32 ] |
|
Julien non effectivement, il nous faut uniquement le rapport "buyer refund by claim closing month" merci à toi claudie |
| Commentaire de Julien Girardet [ 17/juil./09 16:39 ] |
|
Bonjour Claudie, Tu trouveras l'historique du rapport « Buyer refund by claim closing month » pour 2007, 2008 et 2009 dans le répertoire : T:\BI\00 - Projets\2009-07 Historique Buyer Refund 2007 - Buyer refund by claim closing month.xlsx 2008 - Buyer refund by claim closing month.xlsx 2009 - Buyer refund by claim closing month.xlsx L'historique a été généré le jour de la stabilisation des chiffres du mois de Juillet, c'est-à-dire le 07/07/2009 A ta disposition si tu as des questions. Julien. |
| Commentaire de Dalila Belkebir [ 30/sept./09 13:44 ] |
|
Bonjour Claudie, Peut-on clôturer ce JIRA STP ? Merci. cdlt, Dalila. |
| Commentaire de Claudie Dufresne [ 01/oct./09 11:36 ] |
|
bonjour Dalila, oui vous pouvez le cloturer. nous aurons à nouveau besoin de faire une édition de ces rapports d'ici la fin d'année, mais j'ouvrirai un nouveau JIRA merci à toi claudie |
| Commentaire de Dalila Belkebir [ 01/oct./09 11:38 ] |
|
Merci de ton retour Claudie. OK pour le JIRA de fin d'année ! Cdlt, Dalila. |
[BIN-602] [Sales] : rapport France - Advert and product count by family and product type fichier toujours en erreur Création: 04/juil./09 17:22 Mise à jour: 02/nov./09 11:02 Résolue: 17/juil./09 11:36 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Gaël Seguillon | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour malgré la planification avec invite par type de produits je n'arrive pas à sortir le rapport France - Advert and product count by family and product type sur CD et Livres les rapports restent en erreur ce rapport nous permet de suivre l'évolution du nbre d'annonces actives et du taux de couverture de la base de données Gaël |
| Commentaires |
| Commentaire de Agathe Remy [ 15/juil./09 17:53 ] |
|
Bonjour Gaël, S'il te plait, peux-tu préciser dans quel dossier se trouve ce rapport? Merci. Agathe |
| Commentaire de Agathe Remy [ 15/juil./09 19:26 ] |
|
Bonsoir Gaël, Pour Livre, tu essaie d'extraire plus de 4.2 millions de FP, ce qui est beaucoup trop pour BI. Essaie encore d'affiner ton découpage : par exemple en sélectionnant une période de création de la fiche produit ou en découpant par qualité d'annonce (Neuf, Comme neuf, Etat correct, etc..) De même, pour les CD, ton extraction dépasse les 800 000 FP... D'autre part, je te conseille fortement d'éviter de programmer tes planifications à la même heure le même jour : en effet, elles vont se neutraliser en se ralentissant les unes les autres. Il vaut mieux échelonner les planifications dans le temps. Agathe |
| Commentaire de Gaël Seguillon [ 16/juil./09 09:07 ] |
|
ok bien compris merci de ton aide Gaël |
| Commentaire de Agathe Remy [ 10/sept./09 15:07 ] |
|
Bonjour Gaël, Est-ce que je peux clôturer ce JIRA? Merci. Agathe |
| Commentaire de Dalila Belkebir [ 30/sept./09 13:47 ] |
|
Bonjour Gaël, Est-ce que je peux clôturer ce JIRA? Cdlt, Dalila. |
[BIN-618] [BackOffice] : Ajout "User Remark" dans USER ACCOUNT Création: 24/juil./09 14:30 Mise à jour: 10/mai/10 14:12 Résolue: 25/sept./09 15:58 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | BackOffice |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Habib-Sylvain Gourguet | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Description |
|
Besoin de pouvoir effectuer des recherches sur le contenu du champ "Remarque" dans le compte d'un utilisateur. Ajouter "User Remark" dans "User account", dans l'univers "USER ACCOUNT". Merci d'avance. |
| Commentaires |
| Commentaire de Agathe Remy [ 31/juil./09 12:48 ] |
|
Bonjour, Nous pouvons créer une dimension permettant d'afficher le champ "Remarque" dans un rapport. En revanche, utiliser cette dimension comme condition pour effectuer des recherches ne sera pas une utilisation normale du BI et donc risque d'avoir des performances très médiocres. Est-ce que tu veux quand même que nous ajoutions cette information? Merci de ton retour, Agathe |
| Commentaire de Habib-Sylvain Gourguet [ 31/juil./09 13:36 ] |
|
Oui, avoir cette info serait tout de même utile. On pourra obtenir un résultat proche de celui recherché en affinant la requête. Merci. |
| Commentaire de Dalila Belkebir [ 25/sept./09 15:58 ] |
|
Bonjour Habib, La demande a été livrée, peux-tu stp nous la valider pour clôture du JIRA ? Merci. Cdlt, dalila. |
[META-TACHE] Modification des tracking sites-under + tracking e-mails questions
(APP-26706)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 69.0.1.0 (MeV 4G Info - Lot 2) |
| Type: | Sous-tâche | Priorité: | Mineur |
| Rapporteur: | Ghislain Gridel | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
clubic appel à facture mensuel.JPG
rapport hebdo clubic.bmp
rapport hebdo clubic.bmp
rapport hebdo clubic.JPG
|
| Pays: |
FRA - France
|
| Projets PM: | *** A PLANIFIER *** |
| Commentaires |
| Commentaire de Ghislain Gridel [ 23/oct./09 10:27 ] |
|
Bonjour, clubic a accepté le changement de rémunération. Le contrat est en cours de rédaction. Peut-on modifier le rapport automatique svp ? PriceMinister : Partner - Weekly revenue by tracking group PriceMinister : Clubic - Appel à facture mensuel Il faut modifier : - le VA capturé en commission capturée - La rémunération de 8% du VA capturée à 57.5% de la commission capturée Le nombre de paniers ne change pas. Merci ! Ghisalin |
| Commentaire de Ghislain Gridel [ 23/oct./09 10:38 ] |
| indications détaillées ci-joint |
| Commentaire de Dalila Belkebir [ 27/oct./09 11:45 ] |
|
Bonjour, La modification doit être apportée pour quand ? pour un appel à facture sur les chiffres d'octobre ? de Novembre ? Pourrions nous avoir l'extrait du contrat qui parle de la rémunération afin de bien vérifier les calculs à implémenter ? Merci de votre retour. Cdlt, Dalila. |
| Commentaire de Mathilde Caby [ 27/oct./09 12:04 ] |
|
Bonjour Dalila, C'est Mathieu qui s'occupe de Clubic, il ne revient que vendredi. Je peux déjà te dire que ces nouveaux rapports seront nécessaires pour la facturation de novembre (pas d'octobre) Bonne journée Mathilde |
| Commentaire de Mathieu Richomme [ 30/oct./09 12:48 ] |
|
57.5% de la commission hors taxe hors frais de port cf les 2 schémas de Ghislain le contrat est en cours de validation par le service juridique du partenaire mais il ne servira pas à grand chose pour notre rapport BI : nous n'indiquons pas dans le contrat s'il s'agit de la commission hors frais de port ou avec frais de port le modèle change à partir du 1er novembre, le partenaire doit continuer à recevoir les rapports hebdo avec la nouvelle rem pour avoir une visibilité sur la transfo merci Mathieu |
| Commentaire de Mathieu Richomme [ 09/nov./09 11:14 ] |
|
les rapports envoyés aujourd'hui au partenaire n'ont pas été modifiés le nouveau modèle de rémunération est pourtant déjà en place le partenaire est donc dans l'incapacité de faire des optimisations quand pourrons-nous avoir les nouveaux rapports ? d'avance merci |
| Commentaire de Dalila Belkebir [ 09/nov./09 11:50 ] |
|
Mathieu, désolée, j'ai mal lu et j'ai cru comprendre que tu en avais besoin pr le reporting mensuel. Les rapports sont prêts, je les valide ce jour et te les mets à dispo en production. Cdlt, Dalila. |
| Commentaire de Christophe Garcia [ 27/mai/10 14:19 ] |
| MDPLVC |
[EXP-4998] Impossible de me connecter au BO de PROD Espagne Création: 02/nov./09 15:47 Mise à jour: 04/janv./10 17:52 Résolue: 04/janv./10 17:52 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Ariane Baldinger | Attribution: | Jérémie Bennejean |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ESP - Espagne
|
| Description |
|
Ca fait plus d'une semaine que je ne peux plus me connecter au BO de Prod Espagne sous FF. |
| Commentaires |
| Commentaire de Gaël Seguillon [ 03/déc./09 14:03 ] |
|
Bonjour on un souci persistant pour se connecter au BO espagne, il faut revalider à plusieurs reprises pseudo et mot de passe, ce qui est gênant pour moi est que je ne peux plus ouvrir directement les liens des rapports BI, je suis obligé de faire du copier coller dans le navigateur pour avoir accès aux pages des liens pas forcément optimal en terme de fonctionnement. merci Gaël |
| Commentaire de Laura Yeo [ 03/déc./09 14:54 ] |
|
Problème bien connu au SAV ES, il faut presque quotidiennement valider 3/4 fois le log+mdp avant de pouvoir se connecter au BO ES. Navigateur utilisé: Firefox version 3.0.10 (des fois que...) Laura. |
| Commentaire de Stéphanie BOILLON [ 03/déc./09 15:38 ] |
|
Problème également de mon coté, qui m'empêche parfois de traiter directement sur le BO ES. Parfois besoin d'une 10aine de tentatives ... De plus, il m'est impossible de cocher la case pour enregistrer le mot de passe, je dois donc le retaper à toutes les tentatives. Stephanie. |
| Commentaire de Jérémie Bennejean [ 21/déc./09 15:29 ] |
|
Hello, J'ai vu une erreur de syntaxe dans la conf jboss d'un des serveurs sur lequel la probabilité de se connecter est forte. Après le redémarrage de demain matin, les changements seront effectifs. Je pense que cela devrait corriger le problème. Merci. Jérémie. |
| Commentaire de Laura Yeo [ 21/déc./09 16:01 ] |
|
Super, on espère tous que ça va résoudre le pb. Merci! |
| Commentaire de Ariane Baldinger [ 22/déc./09 10:11 ] |
|
ça marche de mon côté Merci |
| Commentaire de Jérémie Bennejean [ 23/déc./09 16:41 ] |
| C'est bon pour tout le monde ? |
| Commentaire de Laura Yeo [ 23/déc./09 16:59 ] |
| Perfect côté BO, gracias. |
[BIN-635] Historique des rapports "buyer refund by claim closing month" et "buyer refund without claim by completion month" Création: 16/nov./09 18:10 Mise à jour: 28/janv./10 12:19 Résolue: 10/déc./09 10:03 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Finance |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Claudie Dufresne | Attribution: | Julien Girardet |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Dalila, Julien, Comme vu ensemble, nous aurions besoin d'une édition de l'historique de ces rapports sur la FRANCE : - une première fois le jour de la stabilisation des chiffres de novembre (donc vers le 8-10 déc) ==> pour nous permettre de finaliser quelques analyses et estimations avant la fin de l'année, notamment sur les claims antérieures à 2008. - une deuxième fois le jour de la stabilisation des chiffres de décembre (donc vers le 8-10 janv 2010) ==> ceci pour avoir des rapports mis à jour à la date du 31/12/2009. il faudrait éditer l'historique en trois parties : - une première édition allant de janvier 2001 à décembre 2007 - une édition pour uniquement 2008 - une édition pour uniquement 2009 merci à vous claudie |
| Commentaires |
| Commentaire de Julien Girardet [ 10/déc./09 10:03 ] |
|
Bonjour Claudie, Tu trouveras l'historique du buyer refund ici : T:\BI\02 - Historiques de données\2009-12 Historique Buyer Refund. A ta dispo pour plus d'infos. Julien. |
| Commentaire de Dalila Belkebir [ 28/janv./10 11:12 ] |
|
Bonjour Claudie, Peux-tu nous valider le JIRA pour clôture STP ? Merci. Cdlt, Dalila. |
| Commentaire de Claudie Dufresne [ 28/janv./10 12:06 ] |
|
Dalila, Julien, tout est ok, vous pouvez cloturer le JIRA merci à vous claudie |
[APP-27258] lien "Modifier Mon avis" mort pour certains avis Création: 12/nov./09 12:05 Mise à jour: 28/janv./10 17:54 Résolue: 17/nov./09 17:07 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 61.0.0 (CTN-O) |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | M'hand Hadjoudj | Attribution: | Alexandre Garnier |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
screenshot-1.jpg
|
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM: | *** CHASSE *** |
| Navigateur: | Tous |
| Description |
|
Le lien "Modifier Mon avis" ne fonction pas ni en prod ni en integ dans la page "Mes Avis" essayer avec le login "zodiak91" voir screenshot-1 (Depuis le projet avis lot 2) |
| Commentaires |
| Commentaire de Fabrice Feugas [ 12/nov./09 12:14 ] |
| J'arrive pas à reproduire !!! |
| Commentaire de Alexandre Garnier [ 12/nov./09 12:27 ] |
|
Problème JS (visible aussi sous Firefox) : <script type="text/javascript"> var review-7 = new PM.Review(PM.Review.Page.MY_REVIEWS, "70321557", "-7", "5", "SAMSUNG PLAYER ADDICT OMNIA", "Trés bon téléphone !!!"); PM.Util.addEvent("link_show_form-7", "click", PM.Review.displayForm.bindObj({review: review-7, scroll: false})); </script> --> "missing ; before statement" Surement un problème avec les avis qui possèdent des avis avec des ID négatifs !!!??? |
| Commentaire de Alexandre Garnier [ 12/nov./09 12:35 ] |
|
Ça sent le problème de migration des opinions qui a généré des ids négatifs select review_id from review where review_id < 0; -7 -6 -4 -3 -2 -1 --> faudrait peut-être corriger les ids de ces avis. |
| Commentaire de Alexandre Garnier [ 13/nov./09 12:34 ] |
|
Pour les DBA : * est-ce faisable de corriger des id négatifs avec un script ? (en gros les FK sont vérifiées au commit ou à l'update ?) (en tout cas en dev, j'ai essayé et voir plus bas) * est-ce possible de savoir toutes les FK qui pointent vers les review.review_id ? En DEV j'ai fait : SQL> select review_id from review where review_id < 0; REVIEW_ID ---------- -7 -6 -5 -4 -3 -2 -1 7 rows selected. Elapsed: 00:00:00.01 SQL> update review set review_id = review_seq.nextval where review_id = -1; 1 row updated. Elapsed: 00:00:35.90 SQL> commit; Commit complete. Elapsed: 00:00:00.00 SQL> select review_id from rvw_event where review_id < 0; REVIEW_ID ---------- -7 -6 -5 -4 -3 -2 -1 7 rows selected. Elapsed: 00:00:00.02 SQL> select review_id from review where review_id < 0; REVIEW_ID ---------- -7 -6 -5 -4 -3 -2 6 rows selected. Elapsed: 00:00:00.00 |
| Commentaire de M'hand Hadjoudj [ 13/nov./09 14:39 ] |
| donc, si j'ai bien compris les review_id négative font que le lien ne marche pas c'est ça. (entitiyid !!!) |
| Commentaire de Ayoub Benseghir [ 13/nov./09 14:44 ] |
|
* est-ce faisable de corriger des id négatifs avec un
script ? (en gros les FK sont vérifiées au commit ou à l'update ?) (en
tout cas en dev, j'ai essayé et voir plus bas) Oui, c'est faisable par script (d'ailleurs c'est surement le seul moyen). * est-ce possible de savoir toutes les FK qui pointent vers les review.review_id ? SQL> select table_name from all_constraints where r_constraint_name='PK_REVIEW'; TABLE_NAME ------------------------------ OBSERVATION USR_MESSAGE FEEDBACK REVIEW_GAME |
| Commentaire de Alexandre Garnier [ 16/nov./09 10:01 ] |
| @M'hand : les review_id négatifs font que le JS des formulaires ne fonctionne pas |
| Commentaire de Alexandre Garnier [ 17/nov./09 16:59 ] |
|
Script : Garder les logs pour fournir au BI pour qu'ils fassent la même migration de leur côté. Sinon au passage, je sais pas pourquoi mais il manque la FK des événements avis ... |
[APP-27758] les numéros de facture (paiement sur porte-monnaie) sont bloqués à #100.000 Création: 23/déc./09 11:27 Mise à jour: 26/janv./10 14:32 Résolue: 29/déc./09 16:02 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 59.0.2 |
| Version(s) corrigée(s): | 60.0.0 (TX-L) |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Steven Harel | Attribution: | Arnaud Forgues |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
screenshot-1.jpg
|
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM: | *** CHASSE *** |
| Description |
|
lors d'un transfert des ventes sur le porte-monnaie, un numéro de facture est généré. du type Waaaammxxxxxx avec aaaa : année mm : mois xxx : numéro incrémental les numéros de facture semblent aujourd'hui être bloqués au numéro 100.000 -> tous les transferts après la facture W20091299999 ont le même numéro : W200912100000 ! |
| Commentaires |
| Commentaire de Steven Harel [ 23/déc./09 12:06 ] |
| même chose sur les derniers numéros de facture de novembre |
| Commentaire de Emeric Teil [ 23/déc./09 14:25 ] |
|
Pas mal ça... :o) Question pour être sur : ce numéro est bien remis à 0 au début de chaque échéance de compensation ? si tel est le cas, cela signifie qu'on a eu plus de 100 000 compensations sur les dates concernées ? |
| Commentaire de Steven Harel [ 23/déc./09 15:09 ] |
| le numéro est remis à jour au début de chaque mois. vu le nombre de transferts de ventes, les factures avec les numéros au dessus de 100.000 commencent en ce moment dès le 10 du mois :( |
| Commentaire de Steven Harel [ 23/déc./09 15:37 ] |
| d'après le bi, 234.325 compensations sur le pmv en novembre, 219.153 du 01 au 22 décembre. |
| Commentaire de Arnaud Forgues [ 29/déc./09 14:35 ] |
|
En effet, en réalité c'est depuis septembre 2008 que le problème existe ! Num. Max Total Groupe facture ------------------------------------------------ 58151 58207 W200807 62814 62880 W200808 100000 100992 W200809 100000 163945 W200810 100000 186524 W200811 100000 208958 W200812 100000 211578 W200901 100000 200460 W200902 100000 202775 W200903 100000 192251 W200904 100000 189765 W200905 100000 239073 W200906 100000 181903 W200907 100000 191188 W200908 100000 226929 W200909 100000 240479 W200910 100000 238357 W200911 100000 250151 W200912 Comme vu avec Steven, on va donc à présent limiter à 7 chiffres max au lieu de 5 (comme actuellement). --> Ainsi pour chaque mois de l'année, on aura un numéro de facture qui ira de "0000001" à "9999999". Pour les factures suivantes, ca marchera mais le format d'affichage sera donc sur plus de 7 chiffres, c'est tout. --> On se donne donc un peu de marge en passant à 7 chiffres plutot que seulement 6, car on est déjà à ~250 000 factures par mois, on peut donc imaginer/espérer atteindre le million d'ici quelques années NB : j'ai vérifié avec Philippe, et ces numéros de factures ne sont pas utilisés par la compta. Cependant si on voulait être au carré fiscalement, on devrait avoir un numéro de facture qui incrémente tout au long de l'année et qui se réinitialise 1 seule fois par an et non chaque mois ... mais bon rien d'urgent néanmoins (vu avec PFA) |
| Commentaire de Arnaud Forgues [ 29/déc./09 16:02 ] |
|
Ok ! Commité sur la branche dev_tx. CAJ2009Q4TX |
[BIN-638] EXTRACT CIBLE pour OP mailing postal Colissimo/PM (2) Création: 30/nov./09 13:58 Mise à jour: 04/janv./10 15:25 Résolue: 01/déc./09 14:21 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Charlotte Fachan | Attribution: | Julien Girardet |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Extract final_CelligiblesOPSept09.xlsx
|
| Pays: |
FRA - France
|
| Description |
|
Dalila, comme vu ensemble, ci joint le second extract correspondant à la cible 1 de l'OP Colissimo_Pm de décembre POur rappel : Cible 1 : clients ayant déjà utilisé le service (op sept / oct) => soit une estimation de 3 000 clients Cible 2 : Clients vendeurs PriceMinister (Vendeurs particuliers hors cobrandé ayant réalisé au moins 2 ventes, pas de blacklist, pas de fraudeur, pas de claims, avec adresse postale de paiement en France) avec adresses nettoyées (dédoublonnées du fichier du mailing de sept/ oct et des clients ayant bénéficié de l'offre) => soit une estimation d'environ 25 000 clients Cible 3 : Client base colissimo.fr (dédoublonnés du fichier du mailing de septembre / octobre et des clients ayant bénéficié de l'offre des 3¿)=> soit une estimation d'environ 22 000 clients Il faudrait pouvoir ressortir les critères d'informations suivants correspondant : ID user Adresse CP Ville Je dois l'envoyer ce soir à PN DATA. DItes moi si c'est jouable pour vous aujourd'hui ou pas ! A votre dispo pour plus d'infos Merci Charlotte |
| Commentaires |
| Commentaire de Dalila Belkebir [ 30/nov./09 14:16 ] |
|
Charlotte, On va essayer de faire le maximum pour te sortir ce dont tuas besoin. Toutefois, comme vu ensemble ce matin, nous devons rédiger une requête et la relancer plusieurs fois pour avoir les infos sur l'ensemble de ton échantillon. Julien s'en occupe. cdlt, Dalila. |
| Commentaire de Julien Girardet [ 30/nov./09 18:13 ] |
|
Désolé Charlotte, mais je ne pourrais pas te fournir les données ce soir. Je vais essayer pour demain midi. Pour info, retrouver les users a partir d'un mail c'est tres long... Julien. |
| Commentaire de Charlotte Fachan [ 30/nov./09 18:28 ] |
| ok merci |
| Commentaire de Julien Girardet [ 01/déc./09 14:21 ] |
|
Charlotte, L'extract est dispo ici : T:\BI\01 - Demandes ponctuelles\2009-12 Extract OP colissimo JIRA Le fichier est : Extract OP colissimo_2.xlsx Julien. |
| Commentaire de Charlotte Fachan [ 01/déc./09 17:09 ] |
|
Super merci Julien pour ta récativité. Charlotte |
| Commentaire de Charlotte Fachan [ 01/déc./09 17:11 ] |
|
Juste une question : pourquoi y a t- il plus de ligne dans
le nouvel extract que dans le fichier initial transmis (environ 30 de
plus) ? Merci Charlotte |
| Commentaire de Julien Girardet [ 01/déc./09 17:15 ] |
|
Car pour un mail, tu peux trouver plusieurs comptes. |
| Commentaire de Charlotte Fachan [ 01/déc./09 17:32 ] |
| ok merci |
[APP-27452] Bug sur le TAG Zanox sur un nombre non significatif de panier Création: 30/nov./09 14:27 Mise à jour: 08/janv./10 17:01 Résolue: 04/janv./10 17:48 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Affiliation |
| Affecte la/les version(s): | 57.0.2 |
| Version(s) corrigée(s): | 59.0.3 |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Mathilde Caby | Attribution: | Olga Costa |
| Résolution: | Aucune correction envisagée | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM: | *** A PLANIFIER *** |
| Description |
|
Bonjour, La technique de Zanox nous remonte des BUG sur certain panier: ID est remplacé dans ces bug par: $purchase.AffiliationRef Cela corresponds à 25 paniers depuis le mois de novembre. Voici les dates auxquels ils sont remontés: 27.11.2009 21:13:04 27.11.2009 13:15:52 23.11.2009 21:27:38 23.11.2009 15:03:43 23.11.2009 13:37:04 22.11.2009 21:44:42 21.11.2009 09:53:11 20.11.2009 17:44:58 19.11.2009 19:10:03 16.11.2009 20:47:26 16.11.2009 20:24:26 15.11.2009 14:30:21 15.11.2009 13:16:14 14.11.2009 16:13:40 14.11.2009 12:51:35 12.11.2009 23:00:57 11.11.2009 16:27:57 10.11.2009 17:53:25 09.11.2009 23:16:36 07.11.2009 23:40:36 06.11.2009 11:32:43 04.11.2009 20:22:35 04.11.2009 13:51:39 03.11.2009 19:21:49 01.11.2009 14:43:17 Aucune donné du panier ne remonte donc. Je reste à votre disposition pour en discuter Merci Mathilde |
| Commentaires |
| Commentaire de Olga Costa [ 03/déc./09 15:59 ] |
| Nous avons dans le tag OrderID=[[$!purchase.AffiliationRef]] et on recouper le numéro de la commande. Et le numéro commande et obligatoire si je ne me trompe pas, donc cette variable doit toujours avoir une valeur. je vois pas pk sur certain panier elle n'est pas interpréter |
| Commentaire de Jérôme Viviès [ 08/déc./09 15:57 ] |
|
Salut les Devs ! Une idée là-dessus ? On met un "!" devant le "$" ? ou autre ? Sinon je ferme le JIRA... |
| Commentaire de Alexandre Garnier [ 08/déc./09 16:24 ] |
|
Le '!' se met après le '$' ce qui semble déjà la cas pour certains tags mais pas d'autres. Sinon, d'après le code, il n'est pas possible que cette variable soit vide : elle vaut au moins "_" --> c'est donc que le panier n'existe pas dans le contexte --> vérifier que sur toutes les pages/événements où ce tag est censé apparaitre, le panier est bien dans le contexte Théoriquement, il y a du y avoir des logs Velocity qui devraient être remontés en parallèle --> devrait permettre de remonter aux cas où ces tags erronés on été affichés Au passage : panier --> pôle TX aussi qui sont surement plus au courant des variables disponibles dans le panier ! Une dernière remarque : c'est la même que |
| Commentaire de Olga Costa [ 08/déc./09 16:42 ] |
| Le '!' est déjà en place pour ce tag ces tag a pour évènement buy et/ou first buy et je pense que les variables sont bien présentes sur les pages concernées pas ces évènements puisque nous n'avons pas de pb avec d'autres tags (qui utilise mêmes événement et mêmes variables) ??? |
| Commentaire de Alexandre Garnier [ 08/déc./09 16:44 ] |
|
|
| Commentaire de Olga Costa [ 08/déc./09 17:07 ] |
|
Mathilde, est ce que le pb est toujours présente sur les Effialiation ( Pour moi la correction que j'ai fait dans ce jira( |
| Commentaire de Olga Costa [ 08/déc./09 17:08 ] |
| Si non Arnaud tu peux peut être dire plus sur le sujet :) |
| Commentaire de Arnaud Forgues [ 08/déc./09 17:27 ] |
| Malheureusement non, je ne peux pas en dire plus, car même si, comme dit Alex "panier --> pôle TX", ce genre de chose n'est absolument pas géré par le pôle TX. Il s'agit de fonctionnalités (tags, affiliation ...) gérées par le pôle contenu / param pour des demandes market. |
| Commentaire de Mathilde Caby [ 08/déc./09 17:34 ] |
|
Bonjour Olga, Nous ne constatons plus se décalage entre plateforme et bi depuis. Ce phénomène semble donc avoir disparu. Peut-on attendre lundi prochain: je ferai un extract de tous les paniers des 15 premiers jours de décembre et vérifirer l'ensemble des montants. Ca vous va? |
| Commentaire de Olga Costa [ 16/déc./09 10:45 ] |
| Mathilde? |
| Commentaire de Jonathan Gorges [ 16/déc./09 14:26 ] |
|
Bonjour, Nous traitons ce point avec Mathilde demain matin, dès son retour. Merci d'avance pour tout. JG |
| Commentaire de Olga Costa [ 04/janv./10 17:38 ] |
| des news? |
| Commentaire de Jonathan Gorges [ 04/janv./10 17:46 ] |
|
Hello, Le problème semble ne plus se produire. Vous pouvez fermer le Jira. Merci |
[APP-27428] Bug sur le TAG Affilinet depuis le 9/11/2009: ce n'est plus la commission qui remonte chez le partenaire mais le volume d'affaire! Création: 27/nov./09 09:28 Mise à jour: 22/déc./09 14:36 Résolue: 16/déc./09 10:45 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Affiliation, Infoglue |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 58.0.1.1 |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Mathilde Caby | Attribution: | Swan Desportes |
| Résolution: | Aucune correction envisagée | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Affilinet extract panier novembre 2009 avec correction.xlsx
Affilinet extract panier novembre 2009.xlsx
Effiliation extract panier
novembre 2009 qui remontent en montant du panier.xlsx
|
| Pays: |
FRA - France
|
| Projets PM: | *** CHASSE *** |
| Description |
|
Bonjour, Nous constatons un changement sur le TAG Affilinet depuis le 9/11/2009 au matin: Depuis le 1er novembre c'était la commission qui remontait dans le TAG et suite à un bug , depuis cette date, c'est le volume d'affaire qui remonte à nouveau. Nous ne constatons pas le problème sur les autres plateformes d'affiliation. Merci d'avance pour le traitement de ce problème Mathilde |
| Commentaires |
| Commentaire de Mathilde Caby [ 27/nov./09 09:41 ] |
|
Voici le fichier des paniers remontant sur l'extranet de la
plateforme Affilinet pour le mois de novembre avec les montants
correspondant aux paniers. |
| Commentaire de Marion Anfreville [ 27/nov./09 09:45 ] |
|
Semble être lié aux modifications qui sont passées pur Effiliation le 10/11 => |
| Commentaire de Marion Anfreville [ 27/nov./09 09:48 ] |
| Erreur de ma part, la modif que j'indique concerne effiliation (et pas affilinet)... |
| Commentaire de Marion Anfreville [ 27/nov./09 12:00 ] |
|
Vu avec Mathilde. Il semble que le problème s'est rectifié tout seul à partir du 23/11. On ne sait pas d'où vient le problème. Est-ce que tu as trouvé d'autres cas ? |
| Commentaire de Mathilde Caby [ 27/nov./09 12:37 ] |
| Voici les paniers de chez Effiliation qui sont remontés en montant du panier : se sont des bugs mais ils sont relatifs au vue de la somme des transactions Effiliation |
| Commentaire de Mathilde Caby [ 27/nov./09 17:12 ] |
|
J'ai fait le traitement complet des paniers de Affilinet pour le mois de novembre. Il y a dans le fichier: le numéro de panier, la date du panier, le montant qui remonte sur l'extranet de la plateforme du partenaire, le montant de la commission bi , la différence entre les deux. Quand le montant n'est pas égale à 0 c'est qu'il y a un problème dans le Tag Mathilde |
| Commentaire de Renaud Dierickx [ 27/nov./09 17:50 ] |
|
On attend le retour de Swan lundi. Je ne vois pas ce qui s'est passé... |
| Commentaire de Swan Desportes [ 02/déc./09 15:52 ] |
| Pour être plus précis, est ce que le problème court du 10/11 - 5h du mat --> 24/11 - 5h du mat ? |
| Commentaire de Mathilde Caby [ 02/déc./09 17:55 ] |
|
Non il y a quelques paniers qui sont remontés avec le montant panier également en dehors de cette période. exemple: n° 77616670 Mathilde |
| Commentaire de Jérôme Viviès [ 08/déc./09 15:55 ] |
|
Toujours critique comme demande ? On fait quoi là-dessus ? |
| Commentaire de Olga Costa [ 11/déc./09 10:26 ] |
|
Swan je t'assigne le jira car j'ai essayé de croiser de mon
côté mais je ne vois pas pk ce problème est apparut. Les dates
correspondent pas à de dumps. (07/11-26/11). Je sais pas si vous pouvez
dire plus en dev. Sinon on ferme le jira Merci |
| Commentaire de Swan Desportes [ 16/déc./09 09:16 ] |
|
Pour qu'un tel bug se produise, il ne peut s'agir que d'un
problème de contenus IG. Soit un problème de mélange dans les dates de
publication, soit de mélange dans les dumps. Quoiqu'il en soit, tracer
l'origine du problème sera très compliqué et chronophage. Donc je
propose d'en rester là. Principaux enseignements : - les demandes de param nécessitent un traitement particulier, une recette plus rigoureuse - il faudrait réhabiliter les tests de non reg sur les trackings. Pour cela, il faut bien travailler avec CGA en amont pour voir ce qu'il est possible de mettre en place. [CAJ2009Q4CTN] |
| Commentaire de Christophe Garcia [ 16/déc./09 10:21 ] |
| MDPLVC |
[APP-27696] [Hors Version] Paniers avec montants CBV capturés sans cbv créé Création: 16/déc./09 18:15 Mise à jour: 22/mars/10 10:58 Résolue: 29/janv./10 16:22 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 65.0.0 (TX-M) |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Julien Girardet | Attribution: | Arnaud Forgues |
| Résolution: | Corrigé | ||
| Σ Estimation restante: | Non spécifié | Estimation restante: | Non spécifié |
| Σ Temps consacré: | Non spécifié | Temps consacré: | Non spécifié |
| Σ Estimation originale: | Non spécifié | Estimation originale: | Non spécifié |
| Pièces jointes: |
Bug_CBV_sql.txt
BUG_PCH_CBV.xls
BUG_PCH_CBV_221209.xls
BUG_PCH_ENMPTIED_CBV.xls
BUG_PCH_ENMPTIED_CBV_221209.xls
purchase_id.txt
purchase_id.xls
|
||||||||||||||||||||||||
| Liens des demandes: |
|
||||||||||||||||||||||||
| Sous-tâches: |
|
||||||||||||||||||||||||
| Pays: |
FRA - France
|
||||||||||||||||||||||||
| Site: | Prod | ||||||||||||||||||||||||
| Projets PM: | *** RESERVE *** | ||||||||||||||||||||||||
| Description |
|
Salut, Un certain nombre de paniers (+ 900 depuis debut decembre) ont des montants CBV capturés, or aucun cbv n'est créé. Par contre le cbv a bien été souscrit par le user (presence de l'evenement "Souscription de garantie") exemple : http://bo.priceminister.com/purchase_back?action=purchaseview&purchaseid=79535334 http://bo.priceminister.com/purchase_back?action=purchaseview&purchaseid=79536347 http://bo.priceminister.com/purchase_back?action=purchaseview&purchaseid=79528429 ... |
| Commentaires |
| Commentaire de Arnaud Forgues [ 16/déc./09 18:50 ] |
|
Est-il possible d'avoir un fichier excel en PJ de ce JIRA
avec les fameux 500 panier concernés ? Ainsi cela permettrait
d'identifier si ce pb concerne uniquement les CBV non pré-coché à la
base (ie : prix < 5 ¿) ou pas. Merci |
| Commentaire de Julien Girardet [ 16/déc./09 18:58 ] |
| liste des purchase_id concernés par le bug cbv |
| Commentaire de Julien Girardet [ 16/déc./09 18:59 ] |
| en excel |
| Commentaire de Julien Girardet [ 17/déc./09 14:12 ] |
|
Liste des paniers capturés avec montants CBV capturés mais sans CBV créé => depuis 01/11/09 |
| Commentaire de Julien Girardet [ 17/déc./09 14:13 ] |
|
Liste des paniers annulés avec montants CBV capturés mais sans CBV créé => depuis 01/11/09 |
| Commentaire de Julien Girardet [ 22/déc./09 17:40 ] |
| Liste des paniers capturés victimes du bug depuis 02/12/09 05h00 |
| Commentaire de Julien Girardet [ 22/déc./09 17:46 ] |
| Liste des paniers annulés victimes du bug depuis 02/12/09 05h00 |
| Commentaire de Habib-Sylvain Gourguet [ 23/déc./09 09:58 ] |
|
Cas rencontré sur un cancelled : http://bo.priceminister.com/purchase_back?action=purchaseview&purchaseid=79845782 Le montant du CBV est tout de même prélevé sur le PMV : http://bo.priceminister.com/wallet?action=view&opid=521711494 |
| Commentaire de Arnaud Forgues [ 29/janv./10 16:21 ] |
|
Ci-dessous les derniers échanges/conclusions avec les BOW concernés (Thomas / Julien / Philippe) : Thomas : - Un client qui aurait pris un cbv lors de la période du bug retrouvera t-il dans son suivi de commande la possibilité de le faire jouer ? - Le SAV est il au courant ? - En avez vous parlé à un référent biz autre que moi par mail ? pkr ou autre ? pour qu'on puisse décider des suites à donner à ce bug ? Arnaud: Voici enfin des suites concernant le bug CBV du mois de décembre dernier : Pour répondre à Thomas, - A priori non, le lien de déclaration de sinistre ne devait pas s'afficher dans le « suivi article acheté ». Cependant le mail de bilan de commande précisait bien le montant du CBV payé ainsi qu'un lien d'aide/information - Oui, le SAV est au courant et a géré le remboursement des 98 comptes pour lesquels les paniers ont été totalement annulés avec prélèvement du CBV - Tout à fait, Philippe était dans la boucle depuis un moment à cause des écarts générés sur la dette vendeur. Concernant les suites à donner à ce bug, j'ai vu Philippe avant-hier, et la décision est de ne rien faire. - En effet, si on décidait de rembourser toutes les garanties non créées (malgré un prélèvement), cela reviendrait à générer 1497 opérations et alerter donc 1497 acheteurs qu'il y a eu un problème, alors que pour la majorité (totalité) d'entre eux, ils n'ont pas voulu / eu besoin de faire jouer leur CBV et n'ont donc pas contacté le SAV. Ce serait donc risqué car cela susciterait trop de questions. - Si on souhaitait recréer à posteriori les garanties, cela représenterait pas mal de travail côté dev puis côté BI/Compta pour la prise en compte de tout cela pour la dette vendeur. Et sachant l'écart généré par rapport au revenus global CBV du mois de décembre, ce ne serait pas pragmatique. Côté chiffre, on constate donc : - 98 paniers annulés avec CBV prélevé  le SAV les a tous remboursés via un crédit PMV (au total environ 68 euros) - 1313 paniers (soit environ 2500 articles) avec CBV prélevés mais non créés  on ne fait rien mais pas de manque à gagner - 5763 paniers (soit environ 12253 articles) avec CBV éligibles mais non créés ni prélevés  manque à gagner D'un point de vue taux de souscription, on avait donc au mois de décembre pour les articles < 5 euros éligibles au CBV : - un total de 288 980 articles - dans les faits, 5 280 CBV réellement créés, soit un taux de 1.83% - En réalité 2 468 CBV prélevés (mais non créés) en plus, soit un taux de 2.68% - Un total de 12 253 CBV éligibles mais non créés ni prélevés, soit un taux théorique de 6.9%  on a donc un manque a gagner sur les articles de moins de 5 euros de 4,2% NB : en PJ (Bug_CBV_sql.txt), le fichier d'analyse qui a permis d'analyser les impacts du bug CBV. |
| Commentaire de Arnaud Forgues [ 01/févr./10 10:45 ] |
| CAJ2010Q1TX |
[APP-28262] Laredoute redirige vers croix-rouge... Création: 10/févr./10 14:25 Mise à jour: 11/févr./10 09:29 Résolue: 10/févr./10 14:39 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Cobrandings |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 62.0.0 (NAV-A) |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Fabrice Feugas | Attribution: | Patrice Boulanger |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM: | *** RESERVE *** |
| Description |
|
Depuis les emails ou même quand on va sur http://laredoute-occasion.priceminister.com/ on est redirigé (une fois de temps en temps) vers pricesolidaire...
|
| Commentaires |
| Commentaire de Patrice Boulanger [ 10/févr./10 14:32 ] |
|
Le problème est sur le serveur Phaeton, le fichier du virtualhost areoudte-occasion est vide: [adminpm@phaeton available]$ ll total 76 drwxrwxr-x 2 adminpm adminpm 4096 May 11 2009 . drwxrwxr-x 4 adminpm adminpm 4096 May 4 2009 .. -rw-rw-r-- 1 adminpm adminpm 609 Oct 22 13:49 bi.priceminister.com -rw-rw-r-- 1 adminpm adminpm 2417 May 4 2009 bo.priceminister.com -rw-rw-r-- 1 adminpm adminpm 1493 May 4 2009 croix-rouge.priceminister.com -rw-r--r-- 1 adminpm adminpm 2321 May 4 2009 epik.priceminister.com -rw-r--r-- 1 adminpm adminpm 2350 May 4 2009 francemobiles.priceminister.com -rw-r--r-- 1 adminpm adminpm 2355 May 4 2009 freesurf.priceminister.com -rw-r--r-- 1 adminpm adminpm 328 May 4 2009 ie8.priceminister.com -rw-rw-r-- 1 adminpm adminpm 333 May 4 2009 img.priceminister.com -rw-rw-r-- 1 adminpm adminpm 524 May 4 2009 intra.priceminister.com -rw-r--r-- 1 adminpm adminpm 2819 May 4 2009 journauxdumidi.priceminister.com -rw-rw-r-- 1 adminpm adminpm 2524 May 4 2009 koobuycity.priceminister.com -rw-r--r-- 1 adminpm adminpm 0 Jan 26 15:59 laredoute-occasion.priceminister.com -rw-r--r-- 1 adminpm adminpm 2514 May 4 2009 lesbonnesaffairesduprogres.priceminister.com -rw-r--r-- 1 adminpm adminpm 2500 May 4 2009 mobilesachat.priceminister.com -rw-r--r-- 1 adminpm adminpm 2303 May 4 2009 nicematin.priceminister.com -rw-rw-r-- 1 adminpm adminpm 2765 May 4 2009 occasion.camif.fr -rw-rw-r-- 1 adminpm adminpm 3758 Sep 21 17:12 preview.priceminister.com -rw-r--r-- 1 adminpm adminpm 2380 May 4 2009 sfr.priceminister.com Apparemment, effacé le 26/01 à 15h59. |
| Commentaire de Patrice Boulanger [ 10/févr./10 14:37 ] |
| C'est corrigé |
| Commentaire de Fabrice Feugas [ 10/févr./10 14:38 ] |
|
Ça vient d'où cette modification ? Quand pourra t-on rétablir le bon fichier ? Au redémarrage demain ? |
| Commentaire de Christophe Garcia [ 10/févr./10 14:38 ] |
| MDPLVC |
| Commentaire de Fabrice Feugas [ 10/févr./10 14:39 ] |
| Merci Patrice. Je pense que ce JIRA fait partie de ceux qui auront eu la durée de vie la plus courte :) |
| Commentaire de Cédric Goldovsky [ 11/févr./10 09:29 ] |
| @ Fabrice : pas forcément la durée la plus courte puisque je le ferme seulement maintenant ^^ |
[BIN-647] Impoossible de planifier le rapport import : Import success rate vs revenue Création: 29/janv./10 11:30 Mise à jour: 25/févr./10 17:11 Résolue: 03/févr./10 18:53 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Finance |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Frédéric Nahum | Attribution: | Dalila Belkebir |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Pour fournir les chiffres à la direction et au commerciaux
sur le C.A que génère les Imports, j'aimerais planifier sur un mois, un
trimestre et un an le rapport :Import success rate vs revenue Mais comme vu avec cyril le rapport tombe ne echec. |
| Commentaires |
| Commentaire de Jérôme Viviès [ 03/févr./10 15:11 ] |
|
Coucou, Savez-vous quand vous pourriez avancer là-dessus ? Ou si ça ne sera pas du tout possible ? Merci ! :) |
| Commentaire de Dalila Belkebir [ 03/févr./10 15:18 ] |
|
Hello, Je regarde ça dans l'après midi. Promis. Cdlt, Dalila. |
| Commentaire de Dalila Belkebir [ 03/févr./10 18:53 ] |
|
A priori quand je planifie sur un seul mois cela passe. En
sélectionnant tous les login (% dans l'invite). en 3 minutes A partir de 2 mois la quantité de données brassées et trop grande et le rapport plante (beaucoup de mise en forme et de calculs aussi dans le rapport). => la problématique est pour la récupération de l'historique. Pour un usage mensuel le rapport est OK en planif. La solution : - planifier chaque lancement sur un seul mois pour avoir les infos de l'historique - et planifier un lancement à partir de maintenant pour avoir les données sur un mois tous les mois. Vous pouvez déjà récupérer les infos que j'ai généré sur l'historique de planification. Cela vous convient ? Cdlt, Dalila. |
| Commentaire de Jérôme Viviès [ 04/févr./10 09:47 ] |
|
Ok, on n'a visiblement pas trop le choix (!) On va se débrouiller avec l'échelon mensuel... Merci ! |
| Commentaire de Dalila Belkebir [ 04/févr./10 11:28 ] |
|
Je viens de refaire des tests en lançant le rapport sur un
trimestre et cela passe en 8 à 10 min... Donc a priori si cela plante
c'est aussi dû à une forte activité sur le BI. Il faudrait faire des
tests de planif sur certains créneaux horaires pour s'assurer d'une
disponibilité du système sur des requêtes sur une période plus longue. Jette un oeil sur mes dernières planifs STP. Par contre, le besoin que tu exprimes aujourd'hui est un besoin non opérationnel ie un besoin plutôt global : bilan sur un trimestre, et sur tous les logins. Le rapport a été initialement développé pour un suivi beaucoup plus précis et détaillé : focus possible sur un user, drill down etc... Si vous avez besoin d'un rapport plus global alors il nous faut vous mettre en place un nouveau rapport. Par exemple un rapport sans l'invite sur le login et une mise en forme plus basique avec juste les indicateurs financiers. Si tu le souhaite tu peux nous faire un JIRA dans ce sens et nous planifierons sa réalisation. A ta dispo si tu souhaites en parler. Cdlt, Dalila. |
| Commentaire de Dalila Belkebir [ 23/févr./10 17:36 ] |
|
Hello Frédéric & Jérôme, Pouvez-vous me valider ce JIRA pour clôture? J'ai notamment vu la création du nouveau JIRA http://pricejira/browse/BIN-650 pour la création d'un nouveau rapport. Nous vous ferons un retour sur la planif de ce besoin. Merci de votre validation. cdlt, Dalila. |
| Commentaire de Jérôme Viviès [ 25/févr./10 17:00 ] |
|
Ok, comme vu ensemble on a plutôt besoin d'un nouveau rapport - cf BIN-650. Donc cette demande-ci est bien close :) |
[APP-28255] Erreur JSON : Caractères spéciaux ? Création: 10/févr./10 10:15 Mise à jour: 02/mars/10 16:32 Résolue: 25/févr./10 14:41 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 61.0.1.2 |
| Version(s) corrigée(s): | 63.0.1 |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Christophe Garcia | Attribution: | Thierry Leforestier |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM: | *** RESERVE *** |
| Description |
|
2010-02-09 06:35:53,260 INFO [-Processor25] 66.249.71.46 - >>> GET http://www.priceminister.com/offer/buy/60644181/Canon-100-200-mm-f-4-5-AF-EOS-Objectif.html 2010-02-09 06:35:53,344 ERROR [-Processor25] 66.249.71.46 - Syntax error in dynamo JSON code : [{"label": "Eos 30 + objectif", "url": "/offer/buy/82170961/canon-eos-30-object if-28-105-usm-grip-bp-300-photo-argentique.html", "edito": "Canon 100 200"},{"label": "Vente occasion eos },{"label": "Eos objectif m42", "url": "/offer/buy/51667973/canon-EOS-B ague-adaptation-objectif-42-Objectif.html", "edito": "Objectif canon 100-200"},{"label": "Eos 300 objectif", "url": "/offer/buy/57575538/Canon-eos-300-objectif-28-90-canon-objec tif-90-300-canon-Photo-Argentique.html", "edito": "Prix objectif canon 100-200"},{"label": "Eos 1000 objectif", "url": "/offer/buy/1677352/Canon-EOS-1000-FN-Photo-Argentique.htm l", "edito": "100/200 canon"},{"label": "Eos objectif 50 f 1.8 occasion", "url": "/offer/buy/2588406/Canon-Objectif-50-mm-f-1-8-II-Canon-EF-Objectif.html", "edito": "Objectif 10 0-200"},{"edito": "Objectif canon autofocus 200mm"}] 2010-02-09 06:35:53,541 INFO [-Processor25] 66.249.71.46 - <<< [281 ms] GET http://www.priceminister.com/offer/buy/60644181/Canon-100-200-mm-f-4-5-AF-EOS-Objectif.html ================================ 2010-02-09 09:57:37,475 INFO [-Processor13] 66.249.71.247 - >>> GET http://www.priceminister.com/offer/buy/17324421/Ub40-Homegrown-In-Holland-Live-DVD-Zone-1.html 2010-02-09 09:57:37,650 ERROR [-Processor13] 66.249.71.247 - Syntax error in dynamo JSON code : [{"label": "Ub40 - live", "url": "/offer/buy/994426/Ub40-Ub40-Live-CD-Album.htm l", "edito": "Ub40 - h2o (live)"},{"label": "Live 1990 holland", "url": "/offer/buy/52680658/Mano-Negra-Manu-Chao-Live-In-Holland-1990-Cd-Album-Cassettes-Mini-disques-Laser-disq ues.html", "edito": "Ub 40"},{"label": "Dvd achat videokid holland", "url": "/offer/buy/1391651/Videokid-VHS.html"},{"label": "Dvd professeur holland", "url": "/offer/buy/148038 7/Professeur-Holland-DVD-Zone-2.html"},{"label": "Acheter ub40", "url": "/offer/buy/15207152/Ub-40-Ub-40-File-CD-Album.html"},{"label": "Dvd opus de holland", "url": "/offer/buy /17699/Kamen-Michael-Mr-Holland-s-Opus-Professeur-Holland-CD-Album.html"},{"label": "Ub40 en live", "url": "/offer/buy/1902287/Ub40-Rockpalast-Live-DVD-Zone-1.html"},{"label": "Cd ub40 live", "url": "/offer/buy/20385/Ub-40-Live-CD-Album.html"},{"label": "Ub40 - h²o {live},{"label": "Cover ub40 live in holland", "url": "/offer/buy/48575776/Ub-40-Cover -Up-CD-Album.html"}] 2010-02-09 09:57:37,827 INFO [-Processor13] 66.249.71.247 - <<< [352 ms] GET http://www.priceminister.com/offer/buy/17324421/Ub40-Homegrown-In-Holland-Live-DVD-Zone-1.html ======================================= 2010-02-09 12:15:17,690 INFO [-Processor75] 192.54.193.26 - >>> GET http://www.priceminister.com/offer/buy/680071/Dogna-Michel-Prenez-En-Main-Votre-Sante-Toutes-Les-Maladies -Courantes-Livre.html 2010-02-09 12:15:17,886 ERROR [-Processor75] 192.54.193.26 - Syntax error in dynamo JSON code : [{"label": "Michel dogna pancreatine", "url": "/offer/buy/82420972/michel-dogna -pratique-de-la-cure-gerson-et-kelley-60-annees-de-succes-therapeutiques-le-saviez-vous-livre.html", "edito": "Michel dogna prenez en main votre santé"},{"label": "Bélanger mich el les ce et la santé", "url": "/offer/buy/831131/Belanger-Michel-Droit-International-De-Sante-Livre.html", "edito": "Livre prenez en main votre sente vol 2"},{"label": "Tous le s cd a la vente de michel dogna", "url": "/s/ann%E9es+60", "edito": "Prenez en main votre santé de michel dogna"},{"label": "Livre du dr dogna", "url": "/s/michel+dogna", "edito ": "Prenez votre vie en main dogna"},{"label": "Michel dogna et la gemmotherapie", "url": "/offer/buy/59516591/Dogna-Michel-Gemmotherapie-Alcoolatures-Meres-Livre.html", "edito" : "Michel dogna prenez votre santé en main"},{"label": "Livreprenez en main votre santé de michel dogna", "url": "/offer/buy/6313129/Dogna-Michel-Prenez-En-Main-Votre-Sante-T-2- Nouvelles-Decouvertes-Livre.html", "edito": "Prenez votre santé en main michel dogna"},{"label": "élixir minéral lipome dogna michel", "url": "/offer/buy/554834/Dogna-Michel-Eli xirs-De-Fleurs-Homoepathiques-Livre.html", "edito": "{livre, prenez en main votre santé, michel dogna, ed. guy trédaniel editeur},{"label": "Livre michel dogna occasion", "url": "/offer/buy/17525200/Dogna-Michel-Grands-Remedes-En-Naturopathie-Livre.html", "edito": "Prenez votre santé en main volume i de michel dogna"},{"label": "Qui est michel dogna", "url": "/offer/buy/46905553/Dogna-Michel-Remedes-Peu-Connus-En-Homeopathie-Livre.html", "edito": "Prenez en main votre santé michel dogna"},{"label": "Michel dogna cd", "url": " /offer/buy/48924205/Dogna-Michel-L-amour-Vainqueur-CD-Album.html", "edito": "Prenez en main votre santé 4éme édition"}] |
| Commentaires |
| Commentaire de Thierry Leforestier [ 10/févr./10 10:54 ] |
|
il s'agit de caractères "{}" présents dans les mots clefs.
Je le traite avec la prochaine turbinamo, ce sont normalement des cas a
la marge. Thierry |
| Commentaire de Christophe Garcia [ 10/févr./10 12:56 ] |
|
En voilà d'autres (peut-être me même pb) {"label": "Atlas jazz django", "url": "/s/jazz+blues+collection", "edito": "Modern jazz quartet django cd occasion"},{"label": "Micro jazz bass original usa", "url": "/offer/buy/62144345/Micro-De-Basse-Electrique-Vintage-Jazz-Bass-Us-Position-Manche-Fender-Instrument.html"},{"label": "Jazz bass reissue 62 usa", "url": "/offer/buy/63080618/Fender-Jazz-Bass-Usa-Reissue-62---Basse-Electrique-Fender-Instrument.html"},{"label": "Jazz story in usa", "url": "/offer/buy/52942857/Harlem-In-Montmartre-A-Paris-Jazz-Story-Between-The-Great-Wars-Livre.html"},{"label": "Cordier jazz django", "url": "/offer/buy/54265448/Jazz-Manouche-La-Grande-Aventure-Du-Swing-Gitan-De-Django-Reinhardt-A-Tchavolo-Schmitt-Livre.html"},{"label": "Django{% import %},{"label": "Jazz impression of usa brubeck", "url": "/offer/buy/55476965/Brubeck-Dave-Quartet-Jazz-Impressions-Of-New-York-33-Tours.html"},{"label": "Modern jazz quartet django", "url": "/offer/buy/56097813/Modern-Jazz-Quartet-Modern-Jazz-Quartet-Django-25-Cm-Barclay-84-007-25-cm.html"},{"label": "Le jazz de a à z django", "url": "/offer/buy/138653/Reinhardt-Django-Le-Jazz-De-A-A-Z-CD-Album.html"},{"label": "Rythme jazz manouche django reinhart", "url": "/offer/buy/2031708/Antonietto-Alain-Django-Reinhardt-Rythmes-Futurs-Livre.html"}] {"label": "Attention fillette livre", "url": "/offer/buy/81122691/granotier-sylvie-mefie-toi-fillette-livre.html"},{"label": "L'attention psychologie selon les modalités deutsh and deutsh", "url": "/offer/buy/66775379/La-Psychologie-Des-Femmes-Tome-I-Enfance-Et-Adolescence-Livre.html"},{"label": "Inhibition neuropsychologie", "url": "/offer/buy/8626776/Coyet-Neuropsychologie-Des-Fonctions-Executives-Livre.html"},{"label": "Attention visuelle livre", "url": "/offer/buy/61626792/Michael-George-Neuroscience-Cognitive-De-L-attention-Visuelle-Livre.html"},{"label": "Orientalisme latent", "url": "/offer/buy/6338190/Said-Edward-W-L-orientalisme-L-orient-Cree-Par-L-occident-Livre.html"},{"label": "Inhibition pathologique", "url": "/offer/buy/1318769/Boujon-Christophe-L-inhibition-Au-Carrefour-Des-Neurosciences-Livre.html"},{"label": "Moutier inhibition", "url": "/offer/buy/1384547/Moutier-Sylvain-Inhibition-Et-Biais-De-Raisonnement-Chez-L-enfant-Et-L-adulte-Livre.html"},{"label": "Riffaterre intertexte latent", "url": "/offer/buy/215641/Riffaterre-Michael-Semiotique-De-La-Poesie-Livre.html"},{"label": "Inhibition laborit", "url": "/offer/buy/342756/Laborit-Henri-Inhibition-De-L-action-Livre.html"},{"label": "Martingales and {m}] {"label": "Avis jean prieur", "url": "/offer/buy/6893114/Prieur-Jean-Les-Temoins-De-L-invisible-Livre.html", "edito": "Saints et saintes photos"},{"label": "Cet audela qui nous attend de jean prieur", "url": "/offer/buy/6893115/Prieur-Jean-Cet-Au-Dela-Qui-Nous-Attend-Livre.html", "edito": "Jean prieur la fontaine de siloé"},{"label": "Chant religieux: saints et saintes de dieu", "url": "/offer/buy/73811318/Saints-Et-Saintes-Quarante-Chants-Volume-1-N-1-Revue.html"},{"label": "Saints et saintes", "url": "/offer/buy/886305/Prieur-Vuillier-Saints-Et-Saintes-De-Savoie-Livre.html"},{"label": "Hitler médium de satan jean prieur", "url": "/offer/buy/974821/Prieur-Jean-Hitler-Medium-De-Satan-Livre.html"},{"label": "Livres de jean prieur j ai lu", "url": "/offer/buy/980694/Prieur-Jean-Hitler-Et-La-Guerre-Luciferienne-Livre.html"},{"label": "Saints et saintes de dieu", "url": "/offer/buy/49395667/Molin-Pierre-Sainte-Vierge-Marie-Saints-Et-Saintes-De-Dieu-Livre.html"},{"label": "Livres avec les saints et saintes { prieres},{"label": "Le pay d apres de jean prieur", "url": "/offer/buy/16994245/Prieur-Jean-Les-Maitres-De-La-Conscience-Planetaire-Livre.html"},{"label": "Vidéo de biographie de saints et saintes", "url": "/offer/buy/46920426/Collection-Vie-Des-Saints-Ste-Bernadette-Soubirous-DVD-Zone-2.html"}] {"label": "Barbara buy", "url": "/offer/buy/81525120/tailleur-barbara-bui-pantalon-et-veste-surpique-turquoise-t-34-36-pret-a-porter.html", "edito": "Augustin barbara"},{"label": "Augustin boujeka", "url": "/s/augustin+boujeka"},{"label": "Aynes augustin", "url": "/s/ayn%E8s+augustin"},{"label": "Barbara castello", "url": "/s/barbara+castello"},{"label": "{augustin lespinasse},{"label": "Augustin lemann", "url": "/s/m+l+abb%E9+augustin+lemann"},{"label": "Augustin dupré", "url": "/offer/buy/600073/Collectif-Augustin-Dupre-1748-1833-Graveur-General-Des-Monnaies-De-France-De-1791-A-1803-Livre.html"},{"label": "Augustin grimault", "url": "/offer/buy/62886292/Histoire-De-L-eglise-Catholique-Au-Senegal---Du-Milieu-Du-Xve-Siecle-A-L-aube-Du-Troisieme-Millenaire-Livre.html"},{"label": "Augustin giovannoni", "url": "/offer/buy/529916/Giovannoni-Augustin-Immanence-Et-Finitude-Chez-Spinoza-Etudes-Sur-L-idee-De-Constitution-Dans-L-ethique-Livre.html"},{"label": "Barbara 47", "url": "/offer/buy/2440684/Collectif-Platine-N-47-Le-Mystere-Barbara-Revelations-Exclusives-Revue.html"}] {"label": "Clinical implications of attachment", "url": "/offer/buy/79934046/-clinical-implications-of-attachment-child-psychology-livre.html"},{"label": "Grounded theory research", "url": "/offer/buy/67265070/Discovery-Of-Grounded-Theory-Strategies-For-Qualitative-Research-Livre.html"},{"label": "G.i. barenblatt scaling, self-similarity and intermediate asymptotics", "url": "/offer/buy/74456063/Scaling-Self-Similarity-And-Intermediate-Asymptotics-Livre.html"},{"label": "Neuro-enhancement", "url": "/offer/buy/87541178/endruweit-meiken-prinzip-zukunft-im-dialog-mit-hans-jonas-livre.html"},{"label": "Geopolitical and geosecurity implications of globalization", "url": "/offer/buy/54199246/The-Geopolitical-And-Geosecurity-Implications-Of-Globalization-Livre.html"},{"label": "Martingales and {m}] {"label": "Edouard hermes", "url": "/offer/buy/68410163/J-ai-Vu-J-ai-Entendu-Livre.html", "edito": "Les grands initiés d'edouard schuré"},{"label": "Jardin de pythagore + hermes", "url": "/s/hermes", "edito": "Edouard schuré"},{"label": "Moise pythagore socrate jesus mahomet", "url": "/s/les+grands+initi%E9s", "edito": "Les grand initie pythagore"},{"label": "Date mort de moise par rapport a jesus", "url": "/offer/buy/50971356/Du-Sinai-A-La-Mer-Morte-De-Moise-A-Jesus-Livre.html", "edito": "Krishma"},{"label": "Les grands initiés schuré", "url": "/offer/buy/19486207/Edouard-Schure-Les-Grands-Inities-Esquisse-De-L-Histoire-Secrete-Des-Religions-Rama-Krishma-Hermes-Moise-Orphee-Pythagore-Platon-Jesus-Livre.html", "edito": "Grands initiés (les), edouard schuré, ed. librairie académique perrin},{"label": "Schure grands inities 1921", "url": "/offer/buy/2159782/Schure-Edouard-Les-Grands-Inities-Esquisse-Ded-L-histoire-Secrete-Des-Religions-Rama-Krishna-Hermes-Moise-Orphee-Pytagore-Platon-Jesus-Livre-ancien.html", "edito": "Cinq grands initiés"},{"label": "Synthèse les grands initiés edouard schuré", "url": "/offer/buy/385699/Schure-Edouard-Les-Grands-Inities-Integrale-Livre.html", "edito": "La vérité des grands initiés"},{"label": "Pythagore et les grands inities", "url": "/offer/buy/392823/Schure-Edouard-Les-Grands-Inities-Livre.html", "edito": "Schuré et les sens"},{"label": "Les grands inities jesus", "url": "/offer/buy/47257687/Les-Grands-Inities-Krishna-Jesus-Pythagore-Rama-Moise-Platon-Hermes-Orphee-Livre.html", "edito": "Livre,grands initiés (les) edouard schuré, ed. librairie académique périn"},{"edito": "Les grand initiés (edouard schuré"}] {"label": "Hutin destock", "url": "/s/benoit+hutin", "edito": "Serge hutin"},{"label": "Gnostiques hutin", "url": "/offer/buy/61082876/Hutin-Serge-Les-Gnostiques-Livre.html", "edito": "Serge hutin livres"},{"label": "Serge hutin societé secrete", "url": "/offer/buy/6563541/Hutin-Serge-Gouvernants-Invisibles-Et-Societe-Secretes-Livre.html", "edito": "Les gouvernants invisibls hutin"},{"label": "Jpg martignoni hutin", "url": "/offer/buy/496739/Martignoni-Hutin-Jean-Pierre-Ethno-Sociologie-Des-Machines-A-Sous-Que-Le-Hasard-Vous-Serve-Mais-Preparez-Vous-A-L-accueillir-Livre.html", "edito": "Maison serge hutin"},{"label": "Jp hutin", "url": "/offer/buy/51580087/Mabrouk-Chien-D-une-Vie-Livre.html", "edito": "Histoire de l'astrologie: science ou superstition serge hutin"},{"label": "Serge hutin hommes et civilisation", "url": "/offer/buy/53250179/Hommes-Et-Civilisations-Fantastiques-Livre.html", "edito": "Livres de serge hutin"},{"label": "Baudouin bonsergent serge hutin", "url": "/offer/buy/1184046/Nostradamus-Les-Propheties-De-Nostradamus-Texte-Integral-Livre.html", "edito": "Livre, hommes et civilisations fantastiques, serge hutin, ed. j'ai lu},{"label": "L'ésotérisme de l'histoire serge hutin", "url": "/offer/buy/1211794/Hutin-Serge-L-esoterisme-De-L-histoire-Livre.html"},{"label": "Homme et civilisation fantastique serge hutin", "url": "/offer/buy/1814566/Hutin-Serge-Hommes-Et-Civilisations-Fantastiques-Livre.html"},{"label": "Serge hutin dedicace", "url": "/offer/buy/47232995/Hutin-Serge-L-amour-Magique-Revelations-Sur-Le-Tantrisme-Livre.html"}] {"label": "Kryeon 2012", "url": "/offer/buy/57825411/Vers-2012-Tome-2-Au-Dela-Du-Voile-Des-Illusions-Et-De-La-Confusion-Kryeon-La-Fraternite-De-Lumiere-Soria-L-archange-Michael-Et-Amma-1cd-Audio-Livre.html", "edito": "Le retour édition kryéon"},{"label": "Kryeon 2009 partenaire avec le divin", "url": "/offer/buy/636444/Kryeon-Partenaire-Avec-Le-Divin-T-4-Livre.html", "edito": "{livre, messages de notre famille, kryeon, ed. ariane},{"label": "Parabole de kryeon", "url": "/offer/buy/636445/Kryeon-Le-Retour-Livre.html", "edito": "Kryeon occasion"},{"label": "Message kryeon", "url": "/offer/buy/636455/Carroll-Messages-De-La-Famille-T-5-Livre.html"},{"label": "Kryeon", "url": "/offer/buy/49285613/Kryeon-Kryeon-5-Messages-De-Notre-Famille-Livre.html"},{"label": "Meditation de kryeon", "url": "/offer/buy/51923060/Collectif-Kryeon-Adama-La-Fraternite-De-Lumiere-Soria-Hildon-Chandra-Et-Flex-Collectif-2007-Le-Retour-De-La-Lumiere-L-annee-Du-Discernement-Spirituel-Cd-De-Meditation-Livre.html"},{"label": "Carroll kryeon", "url": "/offer/buy/56163160/Kryeon-Tome-9-La-Levee-Du-Voile-L-apocalypse-De-La-Nouvelle-Energie-Livre.html"}] {"label": "La captive de la voulte", "url": "/offer/buy/77805529/thibaudet-marguerite-le-coultre-henri-gheon-la-captive-de-la-voulte-livre-ancien.html"},{"label": "Cleopatre captive", "url": "/offer/buy/81835377/jodelle-etienne-cleopatre-captive-livre.html"},{"label": "La captive d'al-ankhara", "url": "/offer/buy/82420237/sandra-marton-la-captive-d-al-ankhara-livre.html"},{"label": "Priere du captif{de la captive},{"label": "Fauvette captive- battmann", "url": "/s/battmann+j+l"},{"label": "Captive 2", "url": "/offer/buy/5986303/Liberation-Captive-2-Jeu-Amiga-Cd-32.html"},{"label": "La captive des highlands", "url": "/offer/buy/61219419/Dickson-Helen-La-Captive-Des-Highlands-Livre.html"},{"label": "Captive enchainee", "url": "/offer/buy/61516483/Wirta-Guy-La-Captive-Enchainee-Livre.html"},{"label": "La captive d'istamboule résumé", "url": "/offer/buy/17707196/Ball-David-Le-Faucon-D-istanbul-T-2-Livre.html"},{"label": "La captive du donjon", "url": "/offer/buy/3659798/Phillips-Tori-La-Captive-Du-Donjon-Livre.html"}] {"label": "La mouche qui a piqué koto", "url": "/offer/buy/82927935/le-sablier-la-mouche-qui-a-pique-koto-livre.html"},{"label": "La mouche pique", "url": "/offer/buy/969597/Mousset-Frederique-Mouche-Qui-A-Pique-Koto-Livre-Cd-Livre.html"},{"label": "Quelle mouche le pique", "url": "/offer/buy/61439258/Noll-Kangoo-Juniors-Tome-2---Quelle-Mouche-Te-Pique-Livre.html"},{"label": "Cédric 5 {quelle mouche le pique?},{"label": "Frédérique mousset", "url": "/offer/buy/537446/Mousset-Frederique-Chipote-Et-Patchouli-Livre.html"},{"label": "Cédric quelle mouche le pique?", "url": "/offer/buy/49146199/Cauvin-Raoul-Cedric-Quelle-Mouche-Le-Pique-Livre.html"}] {"label": "Le larron", "url": "/offer/buy/78179452/larron-le-le-larron-cd-album.html", "edito": "Ultimates n°10"},{"label": "Ultimates 41", "url": "/offer/buy/82377383/ultimates-n-41-revue.html"},{"label": "Ultimates 30", "url": "/offer/buy/70762640/Lot-De-7-Ultimates-Du-N-30-Au-N-36-N-30-Ultimates-Revue.html"},{"label": "Ultimates 32", "url": "/s/ultimates+32+%E0+37++n%B0+6"},{"label": "Ultimates 15", "url": "/s/ultimates+n%B0+15+:+cauchemar(2)"},{"label": "Ultimates 42", "url": "/s/ultimates+x+men++n%B0+42"},{"label": "Ultimates 41 achat", "url": "/offer/buy/59458674/Collectif-Ultimate-X-Men-N-41-Cable-2-Revue.html"},{"label": "Ultimates {2°},{"label": "Ultimates 43", "url": "/offer/buy/61157296/Collectif-Ultimate-X-Men-N-43-Suspense-Revue.html"},{"label": "Bon larron", "url": "/offer/buy/657264/Frere-Stephane-Bon-Larron-Livre.html"}] {"label": "Livre instrument de precision", "url": "/offer/buy/79633047/mitutoyo-m-instruments-de-precision-mecanique-optique-electronique-livre-ancien.html"},{"label": "Sector 200", "url": "/offer/buy/83767600/sector-200-montre.html"},{"label": "Examples of public sector marketing", "url": "/offer/buy/66638263/Marketing-In-The-Public-Sector-A-Roadmap-For-Improved-Performance-Livre.html"},{"label": "Democracy and the public service", "url": "/offer/buy/67250356/Democracy-And-The-Public-Service-Livre.html"},{"label": "Livre+vst instrument", "url": "/offer/buy/67352740/Basic-Vst-Instruments-Livre.html"},{"label": "Pa and instrument rack", "url": "/offer/buy/58402254/Korg-05r-W-Expandeur-1-2-Rack-Korg-Instrument.html"},{"label": "Xo: a theory of the morphology-syntax interface", "url": "/offer/buy/52856373/Xo-A-Theory-Of-The-Morphology-Syntax-Interface-Livre.html"},{"label": "Sector 620", "url": "/offer/buy/54887695/Bracelets-Montres-Sector-620-Ebel-Voyager-Tudor-Prince-Omega-Dynamic-Audemars-Piguet-Breitling-Callistino-Fred-Force-10-Carrera-Y-Carrera-Cartier-Pasha-Boucheron-Revue.html"},{"label": "Stiglitz public sector", "url": "/offer/buy/18633507/Joseph-Stiglitz-Economics-Of-The-Public-Sector-Livre.html"},{"label": "Martingales and {m}] {"label": "Michel dogna pancreatine", "url": "/offer/buy/82420972/michel-dogna-pratique-de-la-cure-gerson-et-kelley-60-annees-de-succes-therapeutiques-le-saviez-vous-livre.html", "edito": "Michel dogna prenez en main votre santé"},{"label": "Bélanger michel les ce et la santé", "url": "/offer/buy/831131/Belanger-Michel-Droit-International-De-Sante-Livre.html", "edito": "Livre prenez en main votre sente vol 2"},{"label": "Tous les cd a la vente de michel dogna", "url": "/s/ann%E9es+60", "edito": "Prenez en main votre santé de michel dogna"},{"label": "Livre du dr dogna", "url": "/s/michel+dogna", "edito": "Prenez votre vie en main dogna"},{"label": "Michel dogna et la gemmotherapie", "url": "/offer/buy/59516591/Dogna-Michel-Gemmotherapie-Alcoolatures-Meres-Livre.html", "edito": "Michel dogna prenez votre santé en main"},{"label": "Livreprenez en main votre santé de michel dogna", "url": "/offer/buy/6313129/Dogna-Michel-Prenez-En-Main-Votre-Sante-T-2-Nouvelles-Decouvertes-Livre.html", "edito": "Prenez votre santé en main michel dogna"},{"label": "élixir minéral lipome dogna michel", "url": "/offer/buy/554834/Dogna-Michel-Elixirs-De-Fleurs-Homoepathiques-Livre.html", "edito": "{livre, prenez en main votre santé, michel dogna, ed. guy trédaniel editeur},{"label": "Livre michel dogna occasion", "url": "/offer/buy/17525200/Dogna-Michel-Grands-Remedes-En-Naturopathie-Livre.html", "edito": "Prenez votre santé en main volume i de michel dogna"},{"label": "Qui est michel dogna", "url": "/offer/buy/46905553/Dogna-Michel-Remedes-Peu-Connus-En-Homeopathie-Livre.html", "edito": "Prenez en main votre santé michel dogna"},{"label": "Michel dogna cd", "url": "/offer/buy/48924205/Dogna-Michel-L-amour-Vainqueur-CD-Album.html", "edito": "Prenez en main votre santé 4éme édition"}] {"label": "Mondo et autres histoire clezio lullaby", "url": "/offer/buy/77358745/Mondo-Et-Autres-Histoires.html", "edito": "Mondo et autre histoire résumé"},{"label": "Le clézio jmg mondo et autres histoire resumer", "url": "/offer/buy/7284956/Le-Clezio-J-M-G-Mondo-Et-Autres-Histoires-Livre.html", "edito": "Fiche de lecture mondo et autres histoires"},{"label": "Jean-marie gustave le clézio mondo et autres histoires gratuit", "url": "/offer/buy/880825/Le-Clezio-Jean-Marie-Gustave-Mondo-Et-Autres-Histoires-Livre.html", "edito": "Lecture de mondo"},{"label": "Le clezio mondo gratuit", "url": "/offer/buy/63180570/Mondo-Et-Autres-Histoires-Livre.html", "edito": "Mondo le clezio questionnaire"},{"label": "Mondo et autres histoires le clezio", "url": "/offer/buy/6365433/Le-Clezio-Mondo-Et-Autres-Histoires-Livre.html", "edito": "L oeuvre mondo et autres histoires"},{"label": "Resume j.m.g le clezio dotre histoire de mondo", "url": "/offer/buy/243954/Le-Clezio-Jean-Marie-Gustave-Mondo-Et-Autres-Histoires-Livre.html", "edito": "Mondo et autres histoires texte intégral"},{"label": "Jean marie gustave le clezio mondo et autres histoires folio edition gallimard", "url": "/offer/buy/245753/Le-Clezio-Jean-Marie-Gustave-Mondo-Et-Autres-Histoires-Livre.html", "edito": "Résumé mondo et les autres"},{"label": "Jean-marie gustave mondo le3s personnages", "url": "/offer/buy/483064/Le-Clezio-Jean-Marie-Gustave-Mondo-Livre.html", "edito": "Le livre { mondo et autre histoire },{"label": "J.m.g. le clézio mondo et autres histoires gratuit", "url": "/offer/buy/48918629/Le-Clezio-J-M-G-Mondo-Et-Autres-Histoires-Livre.html", "edito": "Résumé de( mondo et autres histoires)"},{"edito": "Resumé du livre mondo et autre histoires"}] {"label": "Pack bomb factory mbox2", "url": "/offer/buy/77038735/Digidesign-Mbox-2-Factory-Studio-Alimente-Par-Usb-Pro-Tools-Le-Interfaces-Audio-Digidesign.html", "edito": "Cristal case dea factory"},{"label": "Housse dea factory", "url": "/offer/buy/82237526/urban-factory-protect-sleeve-housse-d-ordinateur-portable-null.html"},{"label": "Dea factory chargeur", "url": "/offer/buy/83830094/dea-factory-blue-light-charge-station-recharheable-battery-accessoire-wii.html"},{"label": "Batterie dea factory+acheter", "url": "/offer/buy/88737680/dea-factory-batterie-rechargeable-pour-wiimote-accessoire-wii.html"},{"label": "Lego super pack technic },{"label": "V smile super pack", "url": "/s/console+vsmile"},{"label": "Super pack delux aggression", "url": "/s/mega+pack"},{"label": "Private super pack", "url": "/offer/buy/49484339/Collectif-Private-Super-Pack-N-3-19-Filles-Tres-Chaudes-Revue.html"},{"label": "Super pack 5", "url": "/offer/buy/15609571/Super-Pack-5-Logiciels-Logiciel.html"},{"label": "Da bird super pack", "url": "/offer/buy/18001077/Cof-Indestructibles-1001-Patte-DVD-Zone-2.html"}] {"label": "Prince valiant reesition", "url": "/offer/buy/82358997/prince-valiant-david-bergeaud-edition-perseverance-cd-cassettes-mini-disques-laser-disques.html", "edito": "Prince valiant harold foster edition"},{"label": "Prince valiant edition serg", "url": "/s/prince+valiant"},{"label": "Prince valiant {futuropolis},{"label": "Prince valiant cd zucchero", "url": "/offer/buy/49902501/Alannah-Myles-Et-Zucchero-What-Are-We-Waiting-For-Bof-Prince-Valiant-CD-Maxi.html"},{"label": "Collection prince valiant", "url": "/offer/buy/17996301/Collectif-Aventures-Heroiques-Prince-Valiant-N-8---Bande-Dessinee-Livre.html"},{"label": "Prince valiant nes", "url": "/offer/buy/1820066/Prince-Vaillant-Jeu-Nintendo-Nes.html"},{"label": "Prince valiant games", "url": "/offer/buy/2920372/Prince-Valiant-Version-Euro-Noir-Et-Blanc-Jeu-Game-Boy.html"},{"label": "Musique du film prince valiant", "url": "/offer/buy/2990205/Waxman-Franz-Prince-Vaillant-Prince-Valiant-CD-Album.html"},{"label": "Achat dvd prince valiant", "url": "/offer/buy/48523894/Prince-Valliant-DVD-Zone-1.html"},{"label": "Le prince valiant résumé", "url": "/offer/buy/48862018/Graton-Jean-Michel-Vaillant-Tome-30-Le-Prince-Blanc-Livre.html"}] {"label": "Saints et saintes photos", "url": "/offer/buy/81738765/jean-prieur-saints-et-saintes-de-savoie-livre.html"},{"label": "Chant religieux: saints et saintes de dieu", "url": "/offer/buy/73811318/Saints-Et-Saintes-Quarante-Chants-Volume-1-N-1-Revue.html"},{"label": "Saints et saintes", "url": "/offer/buy/886305/Prieur-Vuillier-Saints-Et-Saintes-De-Savoie-Livre.html"},{"label": "« a travers chants » - volume b ballue", "url": "/s/ballue+jacques"},{"label": "Saints et saintes de dieu", "url": "/offer/buy/49395667/Molin-Pierre-Sainte-Vierge-Marie-Saints-Et-Saintes-De-Dieu-Livre.html"},{"label": "Livres avec les saints et saintes { prieres},{"label": "Saints et images saintes", "url": "/offer/buy/55036257/Image-Pieuse-La-Sainte-Vierge-Et-L-enfant-Jesus-Gerard-David-Art-Catholique-Gravures.html"},{"label": "Vidéo de biographie de saints et saintes", "url": "/offer/buy/46920426/Collection-Vie-Des-Saints-Ste-Bernadette-Soubirous-DVD-Zone-2.html"},{"label": "Vends la clé des chants volume 1", "url": "/offer/buy/48038151/La-Cle-Des-Chants-Vol-1-Im1-Im2-Im3-Livre-De-L-eleve-Cd-Inclus-J-M-Allerme-Ed-Gerard-Billaudot-Partitions-Et-Songbooks-Enfants-Chansons-Musique-Et-Comptines.html"}] {"label": "Saints et saintes photos", "url": "/offer/buy/81738765/jean-prieur-saints-et-saintes-de-savoie-livre.html"},{"label": "Les pays celtiques", "url": "/offer/buy/70238614/Memoire-Oralite-Culture-Dans-Les-Pays-Celtiques---La-Legende-Arthurienne---Le-Celtisme-Livre.html"},{"label": "Chant religieux: saints et saintes de dieu", "url": "/offer/buy/73811318/Saints-Et-Saintes-Quarante-Chants-Volume-1-N-1-Revue.html"},{"label": "Au fils des jours bore", "url": "/s/henri+bore"},{"label": "Saints et saintes de dieu", "url": "/offer/buy/49395667/Molin-Pierre-Sainte-Vierge-Marie-Saints-Et-Saintes-De-Dieu-Livre.html"},{"label": "Prénoms célèbres", "url": "/offer/buy/534381/Benador-Elia-Les-Prenoms-Celebres-De-La-Litterature-Livre.html"},{"label": "Livres avec les saints et saintes { prieres},{"label": "Les jours et es mois en phonitique englais", "url": "/offer/buy/1084679/Ginesy-Phonetique-Et-Phonologie-De-L-anglais-Livre.html"},{"label": "Serie au fils des jours", "url": "/offer/buy/46355847/Historia-Versailles-Au-Fil-Des-Jours-Hors-Serie-4-Livre.html"},{"label": "Vidéo de biographie de saints et saintes", "url": "/offer/buy/46920426/Collection-Vie-Des-Saints-Ste-Bernadette-Soubirous-DVD-Zone-2.html"}] {"label": "Saints et saintes photos", "url": "/offer/buy/81738765/jean-prieur-saints-et-saintes-de-savoie-livre.html"},{"label": "Vidéo saints et saintes", "url": "/offer/buy/73811318/Saints-Et-Saintes-Quarante-Chants-Volume-1-N-1-Revue.html"},{"label": "Saints et saintes", "url": "/offer/buy/886305/Prieur-Vuillier-Saints-Et-Saintes-De-Savoie-Livre.html"},{"label": "Saints et saintes de dieu", "url": "/offer/buy/49395667/Molin-Pierre-Sainte-Vierge-Marie-Saints-Et-Saintes-De-Dieu-Livre.html"},{"label": "Livres avec les saints et saintes { prieres},{"label": "Vidéo de biographie de saints et saintes", "url": "/offer/buy/46920426/Collection-Vie-Des-Saints-Ste-Bernadette-Soubirous-DVD-Zone-2.html"}] {"label": "Sandy stevens - j'ai faim de toi", "url": "/offer/buy/52773476/J-ai-Faim-De-Toi-J-ai-Faim-De-Toi-45-Tours.html", "edito": "Sandy stevens j'ai faim de toi"},{"label": "A vendre sandy stevens", "url": "/offer/buy/10990359/Sandy-J-ai-Faim-De-Toi-45-Tours.html", "edito": "Sandy steven"},{"label": "Sandy j'ai faim de toi maxi 45t pochette", "url": "/offer/buy/30146150/Sandy-J-ai-Faim-De-Toi-Maxi-45-Tours.html", "edito": "Sandy stevens"},{"label": "Sandy - j'ai faim de toi", "url": "/offer/buy/3834528/Sandy-J-ai-Faim-De-Toi-3-Versions-Maxi-45-Tours.html", "edito": "J'ai faim de toi sandy stevens"},{"edito": "Sandy stevens rapidshare"},{"edito": "Photo de sandy stevens"},{"edito": "Cd sandy stevens carrere"},{"edito": "Sandy et steven"},{"edito": "Sandy streeven"},{"edito": "{j'ai faim de toi}] {"label": "Tri pack cars disney", "url": "/offer/buy/81315442/cars-disney-tri-pack-mia-tia-chick-hicks-jouet.html", "edito": "Cars super sticker"},{"label": "Pack cars disney", "url": "/offer/buy/83829471/bi-pack-cars-disney-snot-rod-et-boost-jouet.html", "edito": "Sticker cars disney mural super geant"},{"label": "Stickers cars disney geant", "url": "/offer/buy/75519946/Coffret-Stickers-Geant-Disney-Cars-Neuf.html", "edito": "Super stickers auto"},{"label": "Cars disney pack 5 voitures", "url": "/offer/buy/87961608/cars-disney-pixar-tri-pack-dinoco-showgirl-avec-flash-macqueen-jouet.html"},{"label": "Lego super pack technic },{"label": "Album panini cars disney", "url": "/offer/buy/59342519/Album-Panini-Cars-Autocollants.html"},{"label": "Pack 6 voitures cars disney", "url": "/s/voitures+cars"},{"label": "Stickers cars disney", "url": "/offer/buy/61726519/Decoration-Murale-Film-Cars-Flash-Mc-Queen-Hudson-Disney-Pas-Stickers-Muraux.html"},{"label": "Pack accessoires ds cars disney", "url": "/nav/Jeux-Video-et-Consoles_Accessoires-Jeux-Video/f1/Nintendo+DS/f2/Skin+-+sticker"},{"label": "Pack accessoire ds lite cars disney", "url": "/nav/Jeux-Video-et-Consoles_Accessoires-Jeux-Video/f1/Nintendo+DS/f2/Transport+-+Rangement"}] |
| Commentaire de Thierry Leforestier [ 10/févr./10 13:53 ] |
| en effet, a première vue, ce sont les mêmes cas. |
[BIN-653] [Compta] : Modification du rapport "wallet operation detail by completion date" Création: 19/févr./10 14:53 Mise à jour: 26/mars/10 15:08 |
|
| Etat: | Ouvert |
| Projet: | Business Intelligence |
| Composants: | Bug & Improvement |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Claudie Dufresne | Attribution: | Julien Girardet |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Description |
|
Agathe, Dalila, Nous souhaitons que soit apportée une modification au rapport "wallet operation detail by completion date" Il faudrait ajouter une information donc ajouter une colonne pour faire apparaitre le "user id". Claire qui doit parfois traiter, à notre demande, des transactions en masse a besoin de cette info. merci à vous claudie |
| Commentaires |
| Commentaire de Agathe Remy [ 16/mars/10 14:36 ] |
|
Bonjour Claudie, Stp, peux-tu me confirmer qu'il s'agit bien d'ajouter le user id correspondant au pseudo déjà affiché dans le rapport, à savoir celui du bénéficiaire de l'opération? Merci, Agathe |
| Commentaire de Claudie Dufresne [ 16/mars/10 15:19 ] |
|
Hello Agathe, Claire vient de me confirmer qu'il ne s'agit justement pas du user id correspondant au pseudo dans le fichier. par exemple, pour les paiements vente, il ne s'agit pas du user id du vendeur mais de celui de l'acheteur. à ta dispo si besoin merci à toi claudie |
| Commentaire de Agathe Remy [ 16/mars/10 16:06 ] |
|
Claudie, Si je reprends ton exemple de paiement des ventes, une même opération pouvant correspondre au paiement de plusieurs transactions donc plusieurs acheteurs. Cela voudrait donc dire que pour chaque acheteur la même ligne opération sera dupliquée?! De plus, peux-tu me préciser quels sont les autres cas possibles? Merci, Agathe |
| Commentaire de Julien Girardet [ 26/mars/10 14:58 ] |
|
Bonjour, Voici le CR du point Finance/Backoffice du 25/03/2010 : Existant : Dans le cadre de la régularisation Compta/BackOffice, le BackOffice doit effectuer des opérations de « remboursement à tort » acheteurs. Pour ce faire, la Compta transmet au BackOffice le listing des opérations de type « crédit BO » avec comme cause « Paiement vente » à l'aide du rapport « wallet operation detail by completion date ». Ces opérations correspondent à des paiements vendeurs effectuées manuellement par le BackOffice. (Exemple : Paiement vendeur sur une transaction avec réclamation de type PVZA). Chaque opération « Crédit BO - Paiement vente » correspond à une seule transaction. A partir de l'identifiant article rattaché à l'opération, le BackOffice détermine si l'acheteur à été remboursé à tort et, le cas échéant, crée une opération de débit « remboursement à tort ». Le BackOffice automatise ces opérations de remboursement à tort à l'aide d'un lien qui prend comme paramètre l'identifiant de l'acheteur. Or actuellement, seul l'identifiant article est présent dans le rapport « wallet operation detail by completion date ». Besoin : Connaître l'identifiant acheteur des transactions (articles) ayant une opération finalisée de type « crédit BO » avec comme cause « Paiement vente » L'ajout de l'identifiant acheteur facilitera l'analyse de transaction par le BackOffice (accès direct sur le compte de l'acheteur pour déterminer si il y a eu un remboursement à tort ou non) et la création de l'opération de remboursement acheteur (paramètre du lien). Proposition : Développer un nouveau rapport BI du même type que le rapport « wallet operation detail by completion date » mais uniquement pour les opérations de type « crédit BO » avec comme cause « Paiement vente » et en ajoutant l'identifiant acheteur (buyer account id) de la transaction, ainsi qu'un lien BackOffice vers le compte acheteur. Attention : ce lien ne correspond pas à l'automatisation des remboursements à tort mais uniquement au compte BackOffice acheteur. N'hésitez pas à me faire part de vos retours. Si s'est OK pour tout le monde, nous pourrons rédiger les specs, puis après validation, nous développerons le rapport. Merci, Julien. |
| Commentaire de Claire Durand [ 26/mars/10 15:08 ] |
| c'est parfait pour moi, merci |
[cob] META-TACHE Fermeture LeProgrès
(APP-28357)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Cobrandings |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 67.0.0 (CTN-Q) |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | Fabrice Feugas | Attribution: | Jonathan Gorges |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM: | *** RESERVE *** |
| Commentaires |
| Commentaire de Jonathan Gorges [ 12/mars/10 16:24 ] |
|
Hello, L'e-mail a bien été envoyé comme convenu à l'ensemble des membre de LeProgrès. Merci à l'équipe BI pour l'export des adresses et merci également à Damien Gilloz pour avoir passé du temps sur l'envoi de ce mail. Pour info, nous avons envoyé le message classique de coupure de cob, via Gmail en utilisant l'adresse nepasrepondre@priceminister.com. Après suppression des doublons, environ 420 adresses étaient concernées par cette coupure du cob. Bon week-end. Jonathan |
[BIN-664] [TFV] : Taux de transfo vendeurs Création: 24/mars/10 10:36 Mise à jour: 26/mai/10 18:32 Résolue: 09/avr./10 18:11 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Audrey Angleys | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
DATAS_JIRA_BIN_664_2010.xls
requête_Jira_BIN-664.sql
|
| Pays: |
FRA - France
|
| Description |
|
Hello Comme discuté hier, je cherche à connaitre les taux de transfo: 1) des INA en vendeurs 2) des acheteurs en vendeurs Mon objectif est de voir comment évolue notre capacité à transformer nos vendeurs (en acquisition pure/en migration de profil) et de déterminer si ces taux se dégradent dans le temps. On pourrait regarder le nombre d'INA/d'acheteurs au mois M et regarder à M+3, combien de personnes de ces populations sont devenus vendeurs. Et ensuite comparer ce chiffre à celui de la même époque l'année précédente. Par ex: dans la population des INA/acheteurs du mois de janvier 2010, combien sont devenus vendeurs aujourd'hui? à comparer à: dans la population des INA/acheteurs du mois de janvier 2009, combien étaient vendeurs au 24 mars? A votre dispo si ce n'est pas clair. Merci d'avance pour votre aide! Audrey |
| Commentaires |
| Commentaire de Audrey Angleys [ 06/avr./10 15:51 ] |
|
Salut Agathe, As-tu pu réfléchir à cette demande? J'aurai souhaité agréger ces chiffres dans le cadre de ma présentation de la semaine prochaine (sur la baisse du recrutement des vendeurs). A ta dispo pour en discuter de vive voix Merci d'avance Audrey |
| Commentaire de Cyril Tanneau [ 09/avr./10 18:11 ] |
|
Salut Audrey, tu trouveras dans le dossier ci-dessous le fichier JIRA_664_09042010.xls faisant suite à ta demande. V:\Reporting\BusinessIntelligence\01 - Etudes ponctuelles\2010-04\Jira_ Les règles fonctionnelles du comptage sont indiquées dans l'onglet ReadMe. Peux-tu nous valider ce document? merci, Cyril |
| Commentaire de Audrey Angleys [ 09/avr./10 18:23 ] |
|
Salut Cyril, D'après le doc en PJ, cela semble correspondre à ma demande, merci. En revanche, je n'ai pas le même V:\ que vous, est-ce que tu pourrais le mettre dans T:\ plutôt? Merci beaucoup Audrey |
| Commentaire de Cyril Tanneau [ 09/avr./10 18:28 ] |
|
Audrey, les comptages sont finalement disponibles dans le dossier ci-dessous, en effet tu n'as accès à celui que j'ai indiqué dans le post précédent T:\BI\01 - Demandes ponctuelles\02 - Etudes Marketing\Jira_ Merci, Cyril |
| Commentaire de Cyril Tanneau [ 13/avr./10 11:39 ] |
|
Salut Audrey, As-tu eu le temps de regarder les comptages fournis dans le cadre de cette étude? En ce cas peux-tu valider la demande si cela te convient? Merci pour ton retour, bonne journée, Cyril |
| Commentaire de Audrey Angleys [ 13/avr./10 11:56 ] |
|
Salut Cyril, J'étais justement en train de regarder et cela nous semble assez important comme chiffre (voire bizarre). Du coup on regarde de plus près et je reviens vers toi. Merci Audrey |
| Commentaire de Agathe Remy [ 26/mai/10 18:32 ] |
|
Je ferme cette demande en raison de la livraison de la
nouvelle version du rapport New sellers by first advert date du
20/05/2010. Agathe |
[IMP-5694] FP Pseudo mstore - mentions !!! Garantie Music Store 3 ans !!! - !!! Garantie "Satisfait ou remboursé" 30 jours !!! dans les commentaires Création: 31/mars/10 11:16 Mise à jour: 23/avr./10 10:32 Résolue: 23/avr./10 10:32 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Projet import |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Anthony Briou | Attribution: | Frédéric Nahum |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Login: | mstore |
| Séparateur: | N/A |
| Type de traitement: |
Mise à jour/création annonces avec mise à jour/création produits
|
| Description |
|
les fiches importées par mstore ont les mentions !!!
Garantie Music Store 3 ans !!! - !!! Garantie "Satisfait ou remboursé"
30 jours !!! dans les commentaires, ce qui pose des problème, les types
"instruments" et "sono & matériel de studio" étant en
fonctionnement "fiche public". CF : http://bo.priceminister.com/referential_back?action=notelist&popup=false&productid=92263145 http://bo.priceminister.com/referential_back?action=notelist&popup=false&productid=92264001 http://bo.priceminister.com/referential_back?action=notelist&popup=false&productid=92263817 http://bo.priceminister.com/referential_back?action=notelist&popup=false&productid=98701593 |
| Commentaires |
| Commentaire de Jérome Marianne [ 16/avr./10 16:00 ] |
|
Pour pouvoir mettre à jour toutes ses fiches produits il
faut une extraction BI de son stock avec les ID produits et le
descriptif entre autre, à rajouter en pièce jointe au JIRA. A demander à Dorian ou à Xavier Fabregat s'il sait le faire. |
| Commentaire de Jérome Marianne [ 16/avr./10 16:02 ] |
| Erratum: En fait le commercial qui gère ce pro est Jeremy Pallot et non pas Dorian. |
| Commentaire de Fotigui Tangara [ 20/avr./10 14:18 ] |
|
J'ai mis Gaël et Jérémy Pallot en observateur du Jira. Je
pense plutôt que c'est à Jérémy Pallot de faire l'extraction de stock et
le mettre en copie de ce Jira, car il est le commercial en charge du
partenaire mstore (voir bo), donc mieux placé. |
| Commentaire de Frédéric Nahum [ 23/avr./10 10:32 ] |
|
j'ai corrigé le format d'import de facon a supprimer cette mention au prochain import, Pour les produit restant il faudrait demander cela à l'équipe catalogue |
[EXP-5082] Mise en place technique du partenariat LCL - Affectation de coupons perso aux Adhérents LCL Création: 08/avr./10 17:58 Mise à jour: 10/août/10 10:38 Résolue: 10/août/10 10:38 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Nouvelle fonctionnalité | Priorité: | Majeur |
| Rapporteur: | Jonathan Gorges | Attribution: | Jérémie Bennejean |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
PM - Procédure PriceMinister.ppt
|
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Voici comme convenu la demande de mise en place technique du partenariat LCL / PriceMinister. Petits rappels : ** Contexte : - Opportunité de partenariat entre PriceMinister et le LCL. - Le programme de fidélisation LCL permet aux adhérents de gagner des points par leur comportement bancaire et de les échanger contre des codes d'achat. - Nous voulons que PM soit partenaire et que les adhérents LCL puisse convertir leurs points en code de réduction PriceMinister. - Nous devront donc utiliser le Webservice afin de générer des coupons personnalisés et les affecter à ces différents internautes. ** Objectifs business : - Recrutement de nouveaux acheteurs. Générer du business incrémental via le LCL. - Ce partenariat est également une porte d'entrée dans la domaine bancaire avec de futurs partenariats possibles (si celui-ci fonctionne bien) ** Objectifs "fonctionnel" : - Livrer les coupons aux internautes de manière rapide, fluide (et efficiente de notre côté). - Possibilité d'utiliser le coupon immédiatement sur le site PM par l'internaute, sans formalités supplémentaires par rapport à un visiteur ou client standard. ** Contraintes : - Une même adresse email dans la base PriceMinister peut être affectée à plusieurs comptes différents. - L'adhérent du LCL peut être déjà client PM, ou prospect. ** Autres informations : - Un seul coupon sera utilisable pour le moment : coupon de 10¿ sans minimum, valable sur tout achat (pas nécessairement sur du premier achat). ** Process à mettre en place / demande technique pour Eric : Isilis nous fournira quotidiennement un fichier CSV sur notre FTP avec la liste de tous les internautes ayant converti leurs points en coupon PriceMinister. - Le fichier contiendra uniquement les adresses email des adhérents ayant choisi les coupons PriceMinister. - Comme vu ensemble, nous affecterons les coupons de la manière suivante : a. Si l'adresse email fournie par Isilis est identifiée chez nous sur 1 compte -> nous affecterons ce coupon sur ce même compte. b. Si l'adresse email fournie par Isilis est identifiée chez nous sur plusieurs comptes -> nous affecterons ce coupon sur le dernier compte actif. c. Si l'adresse email fournie par Isilis n'est pas connue dans notre base -> nous créons un compte « contact » en affectant le coupon sur l'adresse email fournie. Le coupon sera directement utilisable par l'internaute une fois le compte PriceMinister créé avec la même adresse email. - En plus de cela, vous générerez automatiquement les dates de création des comptes existants afin de pouvoir affecter les coupons sur ces mêmes comptes. - Pour les comptes existants, vous générerez également automatiquement les login associés aux adresses emails pour affecter les coupons aux bons comptes. Enfin, nous préciserons bien à l'internaute dans l'email automatique envoyé, quelle est la marche à suivre pour utiliser le coupon (quel compte, login, adresse...) Voilà, j'espère ne rien avoir oublié. N'hésitez pas à compléter cette demande si certains points ne sont pas évoqués. Je mets tout le monde dans la boucle (les participants à la micro RU) afin de faciliter la mise en place de ce projet. Eric, sauf erreur de ma part, ce projet devrait faire parti de ta liste de projets prioritaires. Pourrais-tu ainsi me communiquer stp, même très vaguement, une date possible de livraison ? Il s'agit juste pour moi d'informer le partenaire. Merci d'avance pour tout. Jonathan |
| Commentaires |
| Commentaire de Eric Vannier [ 13/avr./10 09:32 ] |
|
Pour le cas ou le contact n'existe pas , il faut créer un
code tracking qui sera utilisé par l'import de contact, ce qui va nous
permettre par la suite de connaitre les nouveaux contacts acquis par ce
biais. Celui-ci devra exister sinon la création des coupons ne sera pas
possible. Merci de me le communiquer dans ce jira. |
| Commentaire de Jonathan Gorges [ 14/avr./10 10:43 ] |
|
Hello Eric, Merci pour ce retour. Cependant, je ne comprends pas très bien l'intérêt de ce code de tracking. Pourrait-on à la place rajouter une colonne dans le fichier CSV qui s'intitulerait "Client ?" avec : Si prospect (compte contact) = 0 Si client (compte PriceMinister) = 1 De cette manière, tu pourras facilement déterminer s'il s'agit d'un compte contact ou d'un compte client. Est-ce possible ? Merci d'avance pour ton retour. Jonathan. |
| Commentaire de Jonathan Gorges [ 15/avr./10 17:50 ] |
|
Vous trouverez ci-joint la procédure de mise en place technique côté Isilis. De mon côté, tout me semble bon (excepté qq petits détails, peu sensibles). Pourriez-vous valider cette procédure de votre côté svp ou y apporter des modifications ? Merci d'avance pour vos retours. Jonathan. |
| Commentaire de Jonathan Gorges [ 20/avr./10 12:14 ] |
|
Hello, Voici comme convenu le First Tracking à affecter aux comptes contact lors des imports : 2297741 (LCL_new_contacts) A votre dispo. Jon |
| Commentaire de Jérémie Bennejean [ 10/août/10 10:38 ] |
| Done. |
Quamedia : Vérification/Mise à jour du tag + ajouts nouveaux codes de tracking
(APP-28836)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Tracking |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 66.0.1 |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | Carole Boucheny | Attribution: | Carole Boucheny |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM: | *** CHASSE *** |
| Description |
|
Il y a 2 soucis avec le code fourni pour Quamedia : _ premièrement, il y a du xml dans ce code et il peut être mal interprété par IG car lui-même est en xml. Olga a déjà rencontré des cas où ça faisait planter ce qu'il y a après. Donc faut-il bien supprimer : /*<![CDATA[*/ ? _ deuxièmement, les info « Type de commande »,« Type de paiement » et « Nom du produit » ne remontent pas. Je ne vois pas pourquoi, ça doit surement venir du js appelé. Est-ce qu'il vaut mieux supprimer cet appel et mettre nos variables comme pour les autres tag ? |
| Commentaires |
| Commentaire de Alexandre Garnier [ 01/avr./10 12:24 ] |
|
1. On peut supprimer les CDATA dans ce cas (c'ets dommage mais on a pas le choix) 2. Je ne vois pas ce que peut être "Type de commande". Je ne suis pas sûr qu'on ai le type de paiement, ni qu'on puisse avoir le nom du produit (on a des articles dans le panier), qui au passage est optionnel. Mais sinon, on pourrait pas envoyer tout ça avec des flux BI plutôt que de multiplier les tags à l'infini ? |
| Commentaire de Alexandre Garnier [ 01/avr./10 15:36 ] |
|
Faire un copier/coller des tags EULERIAN existants (/promotions/Promotions/FR/Affiliation/Emails abandonnistes/*) En faisant attention de bien appeler le ea.js externe et de mettre le bon commentaire "Eulerian Analytics - priceminister-fr / scartamount" autour du code. Ensuite si les tags existants ne comporte pas les informations demandées, c'est qu'elles ne sont pas disponibles : * Type de commande : qu'est-ce que ça veut dire ? * Type de paiement : on a pas * Nom du produit : on a pas |
| Commentaire de Alexandre Garnier [ 01/avr./10 15:37 ] |
| [CAJ2010Q1CTN] |
| Commentaire de Christophe Garcia [ 09/avr./10 18:03 ] |
| MDPLVC |
[APP-29300] Implémentation des tags TradeDoubler Affiliation sur PriceMinister UK et ES Création: 22/avr./10 18:18 Mise à jour: 09/août/10 15:28 Résolue: 15/juin/10 11:45 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Affiliation |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 70.0.2.1 |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Thomas Springett | Attribution: | Ariane Baldinger |
| Résolution: | Corrigé | ||
| Σ Estimation restante: | Non spécifié | Estimation restante: | Non spécifié |
| Σ Temps consacré: | Non spécifié | Temps consacré: | Non spécifié |
| Σ Estimation originale: | Non spécifié | Estimation originale: | Non spécifié |
| Pièces jointes: |
implementation_manual_adv_080418[1].pdf
productfeeds_manual_nov_2003.pdf
secure payment.jpg
|
||||||||||||||||||||||||||||||
| Liens des demandes: |
|
||||||||||||||||||||||||||||||
| Sous-tâches: |
|
||||||||||||||||||||||||||||||
| Pays: |
GBR - Royaume Uni, ESP - Espagne
|
||||||||||||||||||||||||||||||
| Projets PM: | *** A PLANIFIER *** | ||||||||||||||||||||||||||||||
| Description |
|
Bonjour, Veillez trouver ici les aspects techniques et fonctionnels pour l'intégration du TradeDoubler sur lES et UK. Elements à tracker les achats en différenciant les 1ers achats des autres achats ainsi que les 1ères mises en vente Il faut aussi tracker le VA et CA généré par le plateforme. |
| Commentaires |
| Commentaire de Ariane Baldinger [ 27/avr./10 11:06 ] |
|
Salut, il y a déjà des tags Tradedoubler pour tracker tous les achats, en ES et UK. Toujours actifs. En ES on a ce tag : <!-- DEBUT du code Tradedoubler--> <img src="https://tracker.tradedoubler.com/report?organization=934869&event=16084&orderNumber=$purchase.purchaseId&orderValue=$purchase.SumItemPriceNumber¤cy=EUR" width="1" height="1"> <!-- FIN du code Tradedoubler --> avec les codes de tracking suivant : 1304040, 1304041, 1304042, 1304043, 1304044, 1304045, 1304046, 1508040, 1508041 et en UK : <!-- DEBUT du code Tradedoubler--> <img src="https://tbs.tradedoubler.com/report?organization=1348472&event=154392&orderNumber=$purchase.purchaseId&orderValue=$purchase.SumItemPriceNumber¤cy=GBP" width="1" height="1"> <!-- FIN du code Tradedoubler --> avec les codes de tracking suivant : 1366340, 1366341, 1366440, 1366441, 1372141,1380141,1384142,1384143 Devrons-nous les supprimer ? |
| Commentaire de Benjamin Guerville [ 27/avr./10 15:36 ] |
|
je demande à TD et reviens vers vous merci bg |
| Commentaire de Ariane Baldinger [ 03/mai/10 09:39 ] |
|
mail de Benjamin le 30/04 : "Pour info, il est fortement conseillé de remplacer les anciens tags par les nouveaux" |
| Commentaire de Ariane Baldinger [ 20/mai/10 17:19 ] |
|
Thomas, 1. Quelles infos doit-on passer dans le tag qui tracke les 1ères mises en vente ? et dans quels paramètres ? 2. Peux-tu également indiquer les codes de tracking (s'il y en a) que nous devons paramétrer pour chacun des tags, et pour chaque pays ? (les codes de tracking utilisés actuellement sont indiqués + haut dans le jira) Merci! |
| Commentaire de Thomas Springett [ 25/mai/10 12:00 ] |
|
Bonjour, Pour le premier mise en vente l'information que nous devons remonter est le user ID (Même que CJ pour le UK). Tracking : a venir. Thanks, |
| Commentaire de Thomas Springett [ 25/mai/10 14:52 ] |
|
Tracking ES: Tracking code: TDclassic: 1710040 Group: TradeDoubler ES: http://bo.priceminister.es/tracking_back?action=ustgroupsearch&name=&siteid=&start_date=&end_date=26%2F05%2F2010&number_rows=100&x=61&y=12 |
| Commentaire de Thomas Springett [ 25/mai/10 14:56 ] |
|
Tracking UK: Tracking code: TDclassic: 1408140 Group: TradeDoubler UK: http://bo.priceminister.co.uk/tracking_back?action=ustgroupsearch&name=&siteid=&start_date=&end_date=25%2F05%2F2010&number_rows=100&x=32&y=3 |
| Commentaire de Ariane Baldinger [ 26/mai/10 14:03 ] |
|
mail de Bruno de Tradedoubler concernant les identifiants à utiliser : "pour l'Espagne : - organization=934869 - event=16084 (achat) - event= 200384 (first listing) Et pour le UK : - organization=934869 - event=16084 (achat) - event= 200384 (first listing) Explication : afin de simplifier le management et le tracking, nous utiliserons la même organisation pour tous les programmes à venir. Si un de vos partenaire utilise un autre tracking et que vous deviez le garder, merci de me donner des détails afin que je puisse étudier rapidement si une alternative est possible. " |
| Commentaire de Thomas Springett [ 27/mai/10 09:45 ] |
| Pour les tracking Un suffit pout l'achat et mise en vente c'est uniquement les tags qui sont diiferent. |
| Commentaire de Thomas Springett [ 28/mai/10 12:31 ] |
|
Bonjour, Pour le tracking de premier mise en vent il serait plus intéressant de tager le page "activation de boutique" que le soumission d'annonce. environ 25% de vendeur ne franchise pas l'étape activation de compte et nous voulons payer uniquement pour les annonce visible. Si c'est un travaille trop important a réaliser avant le 03/06/2010 nous pourrions le faire a posteriori. Thomas |
| Commentaire de Fabrice Feugas [ 28/mai/10 14:25 ] |
|
Hello, Je pense que le problème que tu auras si tu tagues l'ouverture de boutique, c'est que à moins qu'elle ne se fasse dans la même visite tu risque de perdre le tracking de tradedoubler et donc de ne pas faire remonter le tag. C'est pas bête comme notion de se baser sur l'ouverture de boutique mais il y a des failles je pense... Au pire ce que tu peux faire, c'est un listing via BI des 1ères mises en vente avec annonce visible ayant pour tracking tradedoubler et comparer via excel avec les données remontées à tradedoubler. En faisant le différentiel tu obtiendras toutes les annonces non visibles. Mais habituellement on rémunère toujours sur la première MeV visible ou non je crois. Ce qui est logique qq part, l'affilié a fait son boulot de nous apporter une nouvelle MeV et il a rempli sa part du contrat. Après à nous d'être bon pour faire ouvrir la boutique. |
| Commentaire de Thomas Springett [ 28/mai/10 15:34 ] |
|
Hi, Il y du logique dans les deux sens, En france nous sommes à 8% des mise en vente qui transform en boutique ouverte, pour le UK et ES cest 25%.-- activé UK 9441 - ES 11841 non activé UK 2961 - ES 4520 Par contre le risque de perte de tracking est très important donc il est mieux de rester sur le MeV. |
| Commentaire de Thomas Springett [ 28/mai/10 15:57 ] |
| Pardon, petit precision:qui NE transform PAS en boutique ouverte, |
| Commentaire de Ariane Baldinger [ 31/mai/10 16:06 ] |
|
Au final que fait-on ? Habituellement on tracke l'évènement 'SELLER_ACCOUNT_ACTIVATION" plutôt que 'FIRST_ADVERT' |
| Commentaire de Thomas Springett [ 31/mai/10 16:11 ] |
|
'SELLER_ACCOUNT_ACTIVATION sinon comme disait Fabrice, on risk de ne pas payée pas mal des nouveau vendeur. |
| Commentaire de Thomas Springett [ 31/mai/10 16:25 ] |
|
Sorry:::: 'FIRST_ADVERT' |
| Commentaire de Fabrice Feugas [ 31/mai/10 16:47 ] |
|
@Ariane, habituellement on taggue les 1ères mises en vente sur l'ouverture de la boutique ???! Et s'il y a eu plusieurs mises en ventes avant l'ouverture de la botique, on fait remonter cette info dans le tag ? Comment ça fonctionne ? |
| Commentaire de Ariane Baldinger [ 07/juin/10 09:43 ] |
| param fait pour le dump du 08/06 (cf. sous-tâches) (ES et UK) |
| Commentaire de Fabrice Feugas [ 14/juin/10 18:30 ] |
|
JIRA fils re-ouvert : "Christina Recoules - 14/juin/10 18:16 Tag tradedoubler non présent sur la page secure payment sur uk " |
| Commentaire de Rémi Virlouvet [ 15/juin/10 11:45 ] |
| ok sur buy en uk (dans hidden 1) |
[IMP-5979] sport-access : analyse fichier en trop d'erreur Création: 03/mai/10 17:10 Mise à jour: 03/mai/10 17:51 Résolue: 03/mai/10 17:51 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Support monitoring |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Jérome Marianne | Attribution: | Jérome Marianne |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Login: | sport-access |
| Séparateur: | N/A |
| Type de traitement: |
N/A
|
| Commentaires |
| Commentaire de Jérome Marianne [ 03/mai/10 17:15 ] |
|
Mail du pro en complément: Bonjour, Je viens d'envoyer un fichier de stock par le biais de mon compte FTP. Mais sur chaque ligne j'ai ce message d'erreur : Cette valeur d'attribut "PM08284347" n'est pas permis pour ce type de produit Pouvez-vous m'indiquer quel est le problème ? Merci d'avance. Vincent (sport-access) |
| Commentaire de Jérome Marianne [ 03/mai/10 17:51 ] |
|
Le problème venait d'un bug dans la valeur "type de produit" de la valeur chaussure du mapping. La clé valeur ne renvoyait pas sur la bonne valeur "chaussure". Après correction et retraitement le fichier passe à 100% |
[IMP-6719] changer commentaire annonce FAIR AND FAST Création: 05/août/10 16:46 Mise à jour: 20/août/10 15:54 Résolue: 20/août/10 15:54 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Demande commerciale |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Julien Buhagiar | Attribution: | Fotigui Tangara |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
extraction stock FairandFast 13.08.10.csv.zip
|
| Pays: |
FRA - France
|
| Login: | Fairandfast1 |
| Séparateur: | N/A |
| Type de traitement: |
N/A
|
| Description |
|
Suite au Mettre par défaut le commentaire annonces suivant: ETAT DU LIVRE + Les livres sont expédiés du Royaume-Uni par avion en courrier prioritaire du lundi au vendredi, emballés dans du papier à bulles et expédiés dans des enveloppes rembourrées et devraient arriver dans les 8 jours ouvrables. |
| Commentaires |
| Commentaire de Fotigui Tangara [ 06/août/10 11:57 ] |
| Peux-tu nous fournir une extraction de stock du PRO ? |
| Commentaire de Fotigui Tangara [ 10/août/10 11:24 ] |
| Tu peux avoir l'extraction de stock du PRO depuis l'outil BI mis à disposition de l'équipe commerciale, renseigne toi auprès de Gaël ou Isabelle, ou Anne ou l'équipe BI... C'est beaucoup plus rapide de passer par cet outil interne (BI). D'habitude, nous ne demandons pas de fichier d'extraction de stock à Sellermania ni à Neteven car les fiches produits sont dans notre base.... |
| Commentaire de Julien Buhagiar [ 13/août/10 15:12 ] |
|
Extraction stock dans ton public (Fotigui) En fait je pense que ma demande va être difficile. Chaque début de ses commentaires annonces est différente. Difficile de rajouter un commentaire automatique, en gardant en plus le début du commentaire du pro qui varie sur chaque ligne. A voir... |
| Commentaire de Fotigui Tangara [ 17/août/10 15:13 ] |
|
Il est envisageable de corriger 30 000 annonces sur 35 000 suivant ton commentaire initial. "ETAT DU LIVRE + Les livres sont expédiés du Royaume-Uni par avion en courrier prioritaire du lundi au vendredi, emballés dans du papier à bulles et expédiés dans des enveloppes rembourrées et devraient arriver dans les 8 jours ouvrables.'" |
| Commentaire de Fotigui Tangara [ 20/août/10 15:07 ] |
| Fichier en cours de traitement pour la modification des commentaires d'annonces... |
| Commentaire de Fotigui Tangara [ 20/août/10 15:54 ] |
|
Demande traitée. |
[IMP-6867] Demande de relance de fichier de commande (par flux FTP) Création: 30/août/10 14:32 Mise à jour: 30/août/10 14:47 Résolue: 30/août/10 14:47 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Support entrant |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Daniel Pintamalli | Attribution: | Daniel Pintamalli |
| Résolution: | Aucune correction envisagée | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Login: | PhoneAnPhone |
| Séparateur: | N/A |
| Type de traitement: |
N/A
|
| Description |
|
De : Mehdi [mailto:mehdi@phoneandphone.com] Envoyé : vendredi 27 août 2010 15:20 À : support.pro@priceminister.com; julien.buhagian@priceminister.com Cc : 'Nathalie Monchery' Objet : fichier 24/08/10 / 90301559 Bonjour, Merci de bien vouloir relancer la commande 90301559 qui ne s'est pas exporte dans notre base. Merci d'avance Cdt. |
| Commentaires |
| Commentaire de Daniel Pintamalli [ 30/août/10 14:47 ] |
|
De : Support Pro [mailto:support.pro@priceminister.com] Envoyé : lundi 30 août 2010 14:48 À : 'Mehdi' Cc : 'Nathalie Monchery'; 'julien.buhagian@priceminister.com' Objet : RE: fichier 24/08/10 / 90301559 Bonjour, Comme ce panier a été validé manuellement, le système ne génère pas de fichier par le biais de FTP. Malheureusement, on ne peut pas fournir ce fichier. Cordialement, Daniel Pintamalli |
[APP-7661] Blocage au niveau de la soumission en front de fiches produits bières Création: 27/févr./06 15:02 Mise à jour: 25/juin/07 18:35 Résolue: 28/févr./06 15:40 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Mise en vente |
| Affecte la/les version(s): | 8.1.1 |
| Version(s) corrigée(s): | 8.1.1b |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Ludovic Piot | Attribution: | Geneviève Beaujard |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Site: | Prod |
| Description |
|
Bonjour, Visiblement il y a un problème lors de la soumission de fiche produit de bières, lorsqu'on souhaite créer une annonce pour vendre des bières de type rousse ou ambrée, on sélectionne cet attribut, le processus de création de la fiche et de l'annonce se passe bien, puis lors de la dernière validation, ça bloque.... Voici le message qui apparait: "Cette valeur d'attribut "PM08631260" n'est pas permis pour ce type de produit ou pour ce support." Si, on fait de même en sélectionnant "Blonde" ou "Blanche", ça marche correctement. Mais que se passe t'il? Il y a tjs un marché pour les "Rousses" et les "Ambrées", c'est quoi cette ségrégation....? :-) Merci de regarder cela, que je puisse revenir vers mon partenaire qui soumet ce type de produits. Très cordialement. Ludo |
| Commentaires |
| Commentaire de Fabien Farache [ 27/févr./06 19:13 ] |
|
Il y a un problème que je n'arrive pas résoudre. L'appli répond que la valeur n'est pas mappé or lorsqu'on regarde la valeur à laquelle correspond la clé indiquée on peut s'appercevoir qu'elle est bien mappée pour ce type de produit et ce support. Si on regarde comment sont mappées les autres valeurs correspondant à l'attribut on peut voir qu'il n'y a pas de différence. Je suis allé voir dans les logs et il semblerait qu'il y ait un problème au niveau du $form.goBack() Quelqu'un peut il m'aider svp extrait du log : >>> GET http://preview.priceminister.com/submit?action=submitcomplete&advertid=42200398&appellation=164293&categoryref=164483&compproductid=18709159&conditionnement=168324&contenance=168319&designation=TESTPM+Bi%E8re&prix=500.0&productid=18709158&qualite=EC&quantite=1&stage=200&submitstage=true&typeProduit=163001&x=70&y=13 2006-02-27 19:10:13,732 WARN [-Processor15] FAF-pm - BEGIN_AUDIT work() OLD MODE 2006-02-27 19:10:13,732 INFO [-Processor15] FAF-pm - Updating product 18709158 2006-02-27 19:10:13,807 WARN [-Processor15] FAF-pm - END_AUDIT work() 2006-02-27 19:10:14,499 WARN [-Processor15] FAF-pm - org.apache.velocity.runtime.exception.ReferenceException: reference : template = PMVelocity - Submit form assembly[165667] [line 217,column 16] : $form.goBack() is not a valid reference. 2006-02-27 19:10:14,503 INFO [-Processor15] FAF-pm - <<< [924 ms] GET http://preview.priceminister.com/submit?action=submitcomplete&advertid=42200398&appellation=164293&categoryref=164483&compproductid=18709159&conditionnement=168324&contenance=168319&designation=TESTPM+Bi%E8re&prix=500.0&productid=18709158&qualite=EC&quantite=1&stage=200&submitstage=true&typeProduit=163001&x=70&y=13 |
| Commentaire de Geneviève Beaujard [ 28/févr./06 15:40 ] |
|
J'aime beaucoup la formulation de Ludovic. En fait c'etait un probleme de conf: la categorie 164293 (Ambrée ou Rousse) du formulaire produit n'avait pas le bon attribut. Fabien a corrigé, c'est OK maintenant. |
| Commentaire de Lydia Dali [ 01/mars/06 10:25 ] |
| ok, testé en prod. |
[EXP-1537] Problème de génération des pages statiques sur PHAETON pour le BRAND bo.priceminister.com.jmh Création: 17/mars/06 09:53 Mise à jour: 25/juin/07 18:57 Résolue: 17/mars/06 14:17 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Sébastien Tournay | Attribution: | Ranto Andriambololona |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Sur PHAETON, nous avons les erreurs ci-dessous. Je pense que
c'est lié au fait que nous avons renomé le brand
bo.priceminister.com.jmh en bo.jmh.lan. A corriger donc ASAP. également, il me semblait que l'on devait supprimer la mention 'site de test' en accédant à bo.jmh.lan. Cela devait être livré avec la V812. Visiblement cela n'est toujours pas réglé. Il faut rouvrir le JIRA en question et faire le point avec Christophe. bo.priceminister.com.jmh:../Pseudo-static-pages-script.sh: line 36: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-priceminister/accueil.newtemp: No such file or directory Looking up bo.priceminister.com.jmh bo.priceminister.com.jmh Unable to locate remote host bo.priceminister.com.jmh. Alert!: Unable to connect to remote host. lynx: Can't access startfile http://bo.priceminister.com.jmh/home?page=10&static=true grep: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-priceminister/accueil.newtemp: No such file or directory grep: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-priceminister/accueil.newtemp: No such file or directory mv: cannot stat `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-priceminister/accueil.newtemp': No such file or directory ../Pseudo-static-pages-script.sh: line 36: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-priceminister/livres-bd.newtemp: No such file or directory Looking up bo.priceminister.com.jmh bo.priceminister.com.jmh Unable to locate remote host bo.priceminister.com.jmh. Alert!: Unable to connect to remote host. lynx: Can't access startfile http://bo.priceminister.com.jmh/navigation/default/category/root_books?static=true grep: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-priceminister/livres-bd.newtemp: No such file or directory grep: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-priceminister/livres-bd.newtemp: No such file or directory mv: cannot stat `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-priceminister/livres-bd.newtemp': No such file or directory ../Pseudo-static-pages-script.sh: line 36: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-priceminister/musique-cd.newtemp: No such file or directory Looking up bo.priceminister.com.jmh bo.priceminister.com.jmh Unable to locate remote host bo.priceminister.com.jmh. Alert!: Unable to connect to remote host. |
| Commentaires |
| Commentaire de Ranto Andriambololona [ 17/mars/06 14:06 ] |
|
J'ai corrigé le soucis en suprimmant les entrées http://bo.priceminister.com.jmh sur Phaeton Je reprends le projet migration de bo.jmh.lan dans un autre JIRA [adminpm@phaeton pseudo-static-pages]$ ./Pseudo-static-pages-script.sh Starting with sleeptime = 0 www.radindesbois.com:................ done www.priceminister.com:................ done www.croix-rouge.priceminister.com:................ done virginmega.priceminister.com:................ done tiscalibe.priceminister.com:................ done rfm.priceminister.com:................ done preview.priceminister.com:................ done pcdoccasions.vnunet.fr:................ done ofup.priceminister.com:................ done occasion.rueducommerce.fr:................ done occasion.presence-pc.com:................ done occasion.liberation.fr:................ done occasion.camif.fr:................ done mobilokaz.priceminister.com:................ done mobilesachat.priceminister.com:................ done m6.priceminister.com:................ done m6net.priceminister.com:................ done m6music.priceminister.com:................ done m6game.priceminister.com:................ done koobuycity.priceminister.com:................ done jeuxvideo.priceminister.com:................ done freesurf.priceminister.com:................ done francemobiles.priceminister.com:................ done europe2.priceminister.com:................ done epik.priceminister.com:................ done eglue.priceminister.com:................ done croix-rouge.priceminister.com:................ done cinenow.priceminister.com:................ done bo.priceminister.com:................ done bo.jmh.lan:................ done bi.priceminister.com:................ done bambinoccasion.priceminister.com:................ done |
[DEC-494] integration des données jeu buffalo dans la base Création: 20/sept./06 18:41 Mise à jour: 14/sept./07 15:14 Résolue: 12/févr./07 17:14 |
|
| Etat: | Fermé |
| Projet: | Reporting |
| Composants: | Marketing |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Charlotte Fachan | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
buffalo_no_buyers.txt.gz
contact.csv
contact.zip
contact080107.zip
contact100207.zip
contact11122006.zip
contact230107.zip
contact_15112006.csv
contact_29112006.csv
contact_311006.zip
contact_update_15112006.csv
contact_update_29112006.csv
country.txt
planning prévisionnel extraction.xls
|
||||||||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Description |
|
Salut, ci joint un petit apreçu du projet : On est partenaire d'un concours organisé par Buffalo Grill. Date du jeu-concours : du 9 Octobre 2006 au 9 Février 2007 L'objectif est de compléter notre base de données de contact qualifiés. Les internautes qui s'inscrivent sur le site du jeu, www.gratte-moi.com (non ce n'est pas une blague! ;-) peuvent gagner plusieurs lots soit en jouant au jeu du type "instant-gagnant" qui fonctionne sur un système de ticket à gratter soit par tirage au sort (1 par mois) Lors de l'inscription au jeu, les internautes peuvent accepter de recevoir des offres de PM. Aphélie (l'agence qui s'occupe du jeu) nous envoi le fichier des nouveaux contacts (visiblement une mise à disposition d'une liste sur internet) qu'il faudrait intégrer dans la base PM => c'est sûrement là que tu interviens ! Deuxiéme point : lors des instants gagnants du jeu, nous proposons également aux internautes participant au jeu de recevoir un bon d'achat de 6¿ pour une première commande. Il faudrait également récupérer ces adresses pour pouvoir leur adresser leur bon de réduction. On s'en reparle demain Merci Charlotte |
| Commentaires |
| Commentaire de Charlotte Fachan [ 26/sept./06 12:12 ] |
|
Salut Edouard, on pourrait se voir en début d'aprés midi pour en parler? Merci Charlotte |
| Commentaire de Charlotte Fachan [ 26/sept./06 17:44 ] |
|
Edouard, donc concernant notre partenariat avec Buffalo grill sur le jeu gratte-moi, quelques nouvelles informations Aphélie met à notre disposition une URL pour accéder à la liste des nouveaux inscrits. Je ne dispose pas encore de cet accès. Le fichier sera au format XML a priori. On s'en parle demain. Merci Charlotte |
| Commentaire de Edouard Laurent [ 27/sept./06 18:49 ] |
|
Notre système accepte des fichiers au format texte (CSV):
pour pouvoir intégrer facilement les contacts du jeu gratte-moi il nous
faut trouver un moyen de mettre les données recuperees par le jeu au
format suivant. - 2 fichiers .csv : - Un fichier contact (CSV) : "email;;;is_cultural_subscriber;;tracking_id;;;is_partner_subscriber;is_hightech_subscriber;is_house_subscriber" Sachant que les champs "is_quelquechose" doivent etre positionnés à 0 si le contact ne souscrit pas a la newsletter et 1 si il souscrit etant donnée que c'est une inscription global aux newsletters il faut mettre soit tous les champs "is_quelquechose" a 1 ou 0. - Un fichier contact_update (CSV) : "email;nom;prenom;adresse1;adresse2;cp;ville;id_pays;is_partner_subscriber;is_cultural_subscriber;is_hightech_subscriber;is_house_subscriber" Les champs "is_quelquechose" fonctionne de la meme facon que pour le fichier contact. Le champ code pays doit respecter la norme priceminister voir fichier joint |
| Commentaire de Edouard Laurent [ 18/oct./06 15:22 ] |
|
L'import des contacts dans la base est terminé : voici le comptage des nouveaux inscrits grace au jeu : SQL> select count(*) from user_account where USR_FIRST_TRACKING_ID = 1568140; COUNT(*) ---------- 5020 en fichier attaché, la liste pour Agathe |
| Commentaire de Edouard Laurent [ 18/oct./06 15:25 ] |
|
le bon fichier et le fichier contact.zip il suffit de prendre la premiere colone, email adresse |
| Commentaire de François Le Lay [ 19/oct./06 17:15 ] |
| Ci-joint la liste des contacts qui ne sont pas acheteurs. |
| Commentaire de Edouard Laurent [ 31/oct./06 14:47 ] |
| J'ai fait l'integration des contacts, BI a vous de jouer, le fichier "contact_311006.csv" en fichier attaché. |
| Commentaire de Edouard Laurent [ 31/oct./06 14:47 ] |
| C'est un zip finalement :) |
| Commentaire de François Le Lay [ 02/nov./06 19:08 ] |
|
Les nouvelles personnes à contacter sont dans le fichier dispo à l'URL: http://intra.priceminister.com/stats/export/marketing/buffalo_final_20061102.txt.gz Il y en a 3400 environ, le différentiel a été fait avec les adresses de l'envoi précédent pour ne pas leur parler 2 fois de suite. |
| Commentaire de Jérémie Bennejean [ 15/nov./06 16:14 ] |
|
15/11/2006 Les fichiers sont en PJ : contact_update_15112006.csv contact_15112006.csv |
| Commentaire de Edouard Laurent [ 15/nov./06 16:26 ] |
|
Cela fait : 8338 nouveaux comptes ce coup la et 2665 le coup d'avant |
| Commentaire de François Le Lay [ 17/nov./06 11:37 ] |
|
Les nouvelles personnes à contacter sont dans le fichier dispo à l'URL: http://intra.priceminister.com/stats/export/marketing/buffalo_final_20061117.txt.gz différentiel = 12164 emails sur les 13908. |
| Commentaire de Charlotte Fachan [ 17/nov./06 12:32 ] |
|
merci ! charlotte |
| Commentaire de Jérémie Bennejean [ 29/nov./06 16:41 ] |
|
29/11/2006 Les fichiers sont en PJ : contact_update_29112006.csv contact_29112006.csv |
| Commentaire de Jérémie Bennejean [ 29/nov./06 16:53 ] |
| Il y a 13553 nouveaux comptes. |
| Commentaire de François Le Lay [ 01/déc./06 11:08 ] |
|
Les nouvelles personnes à contacter sont dans le fichier dispo à l'URL: http://intra.priceminister.com/stats/export/marketing/buffalo_final_20061129.txt.gz différentiel = 18698 emails sur les 20875 fournis. |
| Commentaire de Edouard Laurent [ 11/déc./06 12:00 ] |
|
Suite a mon enquete, on a 3 categories : utilisé : on doit les garder a supprimer : on est sur de pouvoir le supprimer out : personne ne se manifeste sur ce flux ?? : attente de la reponse du partenaire write_shopping; Utilisé write_preistrend; A supprimer write_leguide; Utilisé write_ebuyclub; OUT write_cnet; a supprimer write_pangora; Utilisé write_adoc; Utilisé - à confirmer write_clubic; Utilisé write_pricerunner; Utilisé write_jeuxvideo; OUT write_firstcoffee; Utilisé write_icomparateur; OUT write_caloga; Utilisé write_dvdpascher; Utilisé write_zdnet; OUT write_ciao; OUT write_kelkoo; Utilisé write_all_music_box; Utilisé write_cashstore; ?? write_presence_pc; Utilisé write_mobilesachat; ?? write_shopzilla; a supprimer write_soliland; Utilisé write_m6; ?? Pour l'affiliation : effiliation Utilisé cibleclick Utilisé xinek Utilisé tradedoubler Utilisé |
| Commentaire de Edouard Laurent [ 11/déc./06 13:53 ] |
| desole ca n'a rien a voir, ne pas prendre en compte le dernier commentaire |
| Commentaire de Edouard Laurent [ 11/déc./06 15:28 ] |
| Cela fait : 3586 nouveaux comptes, je mets en piece jointe le fichier des nouveaux inscrits pour le DEC |
| Commentaire de Edouard Laurent [ 11/déc./06 15:29 ] |
| contact11122006.zip |
| Commentaire de François Le Lay [ 11/déc./06 17:27 ] |
|
Les nouvelles personnes à contacter sont dans le fichier dispo à l'URL: http://intra.priceminister.com/stats/export/marketing/buffalo_final_20061211.txt.gz différentiel = 4718 emails sur les 5232 fournis. |
| Commentaire de François Le Lay [ 15/déc./06 12:01 ] |
|
J'ai refait tourner buffalo. Le fichier est le même: http://intra.priceminister.com/stats/export/marketing/buffalo_final_20061211.txt.gz |
| Commentaire de Charlotte Fachan [ 15/déc./06 12:16 ] |
|
merci François Charlotte |
| Commentaire de Edouard Laurent [ 08/janv./07 09:49 ] |
|
Charlotte, est ce que tu pourrais ajouter en piece jointe le nouveau planning Merci Edouard |
| Commentaire de Charlotte Fachan [ 08/janv./07 10:10 ] |
|
voilà... Charlotte |
| Commentaire de Edouard Laurent [ 08/janv./07 14:01 ] |
|
Je viens de finir l'integration des contacts Buffalo : je decompte 13 436 nouveaux comptes en piece jointe le fichiers des nouveaux comptes ( sans le dedoublonage) integrer le 8 janv |
| Commentaire de Edouard Laurent [ 08/janv./07 14:02 ] |
| c'est le fichier contact080107.zip |
| Commentaire de Edouard Laurent [ 23/janv./07 13:56 ] |
|
Cela fait 5 292 nouveaux comptes sur cette periode |
| Commentaire de Edouard Laurent [ 23/janv./07 13:57 ] |
|
contact230107.zip fichier a transmettre a mille merci |
| Commentaire de Edouard Laurent [ 12/févr./07 17:13 ] |
|
Cela fait 14 238 nouveaux comptes sur la derniere periode. Le fichier : contact100207.zip La doc de suivi : http://wikiexploit.lan:82/doku.php?id=edouard.laurent:projets:marketing:jeu_buffalo Je ferme le Jira, l'integration est terminé |
[DEC-430] J'ai besoin de rapport hebdomadaire sur les meilleurs vendeurs de neuf d'une part, et d'occasion de l'autre : Création: 31/août/06 16:02 Mise à jour: 14/sept./07 14:55 Résolue: 02/nov./06 12:11 |
|
| Etat: | Fermé |
| Projet: | Reporting |
| Composants: | Trading |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Anne Korchia | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
J'ai besoin de rapport sur les meilleurs vendeurs de neuf d'une part, et d'occasion de l'autre : Avec comme principales caractéristiques : - Le nombre de vente - Leurs stocks - La quantités moyennes par produits - Le prix moyen de vente - Le CA par mois moyen Ceci pour les catégorie suivantes : Livres anciens livres Loisirs créatifs merci |
| Commentaires |
| Commentaire de Agathe Remy [ 02/nov./06 12:11 ] |
|
D'après Pascal, le reporting demandé a été mis en place via 4D en septembre. D'autre part, afin d'éviter de faire le même travail dans 4D et BI, toutes les demandes de reporting doivent être validées au préalable par Pascal. Merci:-) Cordialement, Agathe |
Migration du mécanisme d'import des fichiers de Phaeton vers Bacchus
(EXP-2759)
|
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Evolution |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | Patrice Boulanger | Attribution: | Patrice Boulanger |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Description |
|
Demander à JET de modifier l'enregistrement DNS pour ftp.priceminister.com
|
| Commentaires |
| Commentaire de Patrice Boulanger [ 29/sept./06 13:47 ] |
|
Le TTL de l'enregistrement ftp.priceminister.com est 1
heure. Pendant ce temps (prévoir la journée pour plus de prudence), les
fichiers pourront être déposés sur les deux serveurs FTP pendant ce
temps. Il faut s'assurer que le script ftpCompute sur Hercule récupére
bien les fichiers sur les deux serveurs. Vérifier aussi avec le B.I. l'usage qu'ils font du FTP sur Phaeton. |
| Commentaire de Patrice Boulanger [ 04/déc./06 11:15 ] |
| Done |
[BIN-300] [Finance] : Instabilité des montants en janvier sur Purchases summary by month Création: 07/mars/07 14:49 Mise à jour: 14/sept./07 18:02 Résolue: 27/avr./07 16:29 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Executive |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Philippe Favrot | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Agathe, deux soucis avec le rapport "purchases summary by month" : 1 - écart au niveau des commissions de février avec les chiffres donnés par Titan : commissions produits : Titan : 701 221 euros Bo : 700 990 euros commissions port : Titan : 244 013 euros Bo : 243 890 euros 2 - les chiffres au titre de "captured payment amount", "captured gross merchandized sold" et "concelling amount" pour le mois de janvier ont bougé par rapport à ceux à de début février (alors que le chiffre de "pending amount" était déjà nul). Merci Philippe |
| Commentaires |
| Commentaire de Agathe Remy [ 09/mars/07 15:49 ] |
|
Les chiffres de BI sont à présent identiques à ceux de Titan. En effet, une erreur s'était glissée suite à la mise en production de la nouvelle gestion de la TVA. Elle a été corrigée. Pour étudier ton deuxième point, il me faudrait avoir un peu plus d'informations : au moins les chiffres à début février et leur date de rafraîchissement. Cordialement, Agathe |
| Commentaire de Agathe Remy [ 27/avr./07 16:29 ] |
|
Philippe, Je viens de regarder ton écart sur le mois de janvier entre le refraîchissement début férvrier et celui début mars. En fait, il s'agit d'environ 114¿ qui correspondent à 6 paniers (dont les id sont :41781271,41841327,41845283,42026890,42031986,42075465) autorisés en janvier, puis capturés manuellement le 28/02/2007. En effet, ces paniers étaient passés en capture denied (SIPS capture failed: Opération impossible (erreur de statut)) à priori par erreur et ont finalement été capturés par le BO fin février. Cordialement, Agathe |
| Commentaire de Philippe Favrot [ 30/avr./07 09:22 ] |
|
Merci c'est effectivement ce que j'ai noté en comparant les rapports Titran panier coupon article à deux dates différentes. J'attends maintenant le retour de vacances de Steven pour voir avec lui ce qui s'est passé sur ces transactions et statuer. Philippe |
[DEC-604] [TFV] : Rapport SLTV mensuel Création: 25/juil./07 18:08 Mise à jour: 04/sept./08 14:58 Résolue: 04/sept./08 14:58 |
|
| Etat: | Fermé |
| Projet: | Reporting |
| Composants: | Marketing |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Thomas Beylot | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
comme convenu, petit jira pour signaler le bug identifié sur
le rapport SLTV du mois dernier (en plus du bug du mois d'avant, le
rapport généré n'a en fait pas comptabilisé les datas de juin, comme si
le rapport était mort) merci thomas |
| Commentaires |
| Commentaire de Agathe Remy [ 27/juil./07 17:50 ] |
|
Thomas, Je suis désolée, mais je ne comprends pas bien la nature du problème. J'ai bien compris qu'il y en avait un, mais si tu pouvais détailler un peu, cela nous aiderait beaucoup:-) Agathe |
| Commentaire de Thomas Beylot [ 27/juil./07 18:02 ] |
|
c'est simple, le rapport qui est sorti début juillet a pour
objectif de filer toutes les datas de juin, et si tu ouvres le doc en
fait il n'y a aucune data sur juin... et les datas sur mai sont toujours
pourrites. thomas |
| Commentaire de Agathe Remy [ 04/sept./08 14:58 ] |
|
Suite au transfert des rapports SLTV dans BI, je ferme ce JIRA qui n'a plus lieu d'être... Agathe |
[BIN-356] [Partner/tracking] : Rapport Pangora Création: 10/août/07 11:10 Mise à jour: 24/sept./07 15:21 Résolue: 14/sept./07 18:51 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Partners |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Charles Decaux | Attribution: | Samir Beghdadi |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Je voudrais mettre en place deux rapports pour Pangora avec
qui on va travailler sur un deal rémunéré 10% du VA généré : - envoyer un rapport journalier contenant le volume d'affaires capturé par Pangora sur la journée précédente avec le détail par tracking de son groupe de tracking - envoyer un appel à facture (le 5 du mois) avec le volume d'affaires capturé par le partenaire sur le mois précédent, le montant unitaire (en l'occurrence 10%) et donc son revenu en mettant le détail par tracking de son groupe de tracking. Destinataire du rapport quotidien : n.preteceille@pangora.com Destinataires du rapport mensuel : n.preteceille@pangora.com m.sakakini@pangora.com Format d'envoi : excel pour le rapport quotidien, pdf pour le rapport mensuel Il faudrait bien veiller à ce que la somme des rapports quotidiens correspondent à peu près au montant de l'appel à facture. Merci Charles |
| Commentaires |
| Commentaire de Agathe Remy [ 14/août/07 17:17 ] |
|
Romain, Peux-tu voir comment intégrer cette demande rapidement dans les priorités BI? Merci:-) Agathe |
| Commentaire de Romain Czornomaz [ 27/août/07 17:44 ] |
|
Samir, Je te transfère la demande de Charles. Il faut rédiger les spécifications et développer les 2 rapports. Bon courage, Romain |
| Commentaire de Charles Decaux [ 28/août/07 16:07 ] |
|
Samir, Notre partenariat avec Pangora étant assez ancien, nous avons toujours des paniers avec des trackings anciens car les internautes mettent ces liens trackés dans leurs favoris. Il faudrait donc ne créer le rapport que pour les codes de tracking suivants : 1907040 1907041 1907042 1907043 1907044 1907045 1907046 1907047 1907048 1907049 1907050 1907051 1907052 1907053 1907054 1907055 1907056 1907057 A ta dispo pour en parler et merci |
| Commentaire de Samir Beghdadi [ 03/sept./07 09:58 ] |
|
Bonjour, La demande a été bien traitée, actuellement en attente pour validation. Samir |
| Commentaire de Agathe Remy [ 11/sept./07 18:57 ] |
|
Charles, La liste de tracking que tu nous as transmise a-t-elle pour vocation d'être fixe et définitive? Parce que si l'on veut garder un peu de souplesse pour créer de nouveaux trackings Prangorax qui seraient pris en compte automatiquement dans les rapports, une solution serait de prendre les trackings dont le code est supérieur ou égal à 1907040 (ce sont des compteurs) ou bien dont la date de creation est supérieure ou égale au 10/08/2007. Qu'en penses-tu? A ta dispo pour en discuter. Agathe |
| Commentaire de Agathe Remy [ 14/sept./07 16:53 ] |
| Charles??? |
| Commentaire de Charles Decaux [ 14/sept./07 17:00 ] |
|
Salut Agathe, il faut que le truc soit souple car il se peut qu'on ait envie d'ajouter de nouveaux trackings. A priori on ne va plus utiliser les anciens trackings, donc avec ta reco (soit code supérieur à 1907040 ou date supérieure à 10/08/2007) Merci |
| Commentaire de Samir Beghdadi [ 14/sept./07 18:51 ] |
| à valider |
| Commentaire de Agathe Remy [ 19/sept./07 10:42 ] |
|
Les 2 rapports sont validés. Samir, peux-tu les passer en production? Merci:-) Agathe |
| Commentaire de Agathe Remy [ 19/sept./07 20:08 ] |
|
Charles, Peux-tu valider ces deux rapports avant que nous programmions leur envoi à Pangora? Merci:-) Agathe |
| Commentaire de Charles Decaux [ 24/sept./07 10:10 ] |
| c'est bon merci |
[APP-17720] Parrainage : parrainage d'un même email par deux parrains différents Création: 05/sept./07 16:58 Mise à jour: 16/avr./10 15:26 Résolue: 08/avr./10 10:01 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Parrainage |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 67.0.0 (CTN-Q) |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Agathe Remy | Attribution: | Dispatcher (Pôle CTN) |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM: | Parrainage (Lot 1) |
| Classif FONC: | parrainage |
| Description |
|
Voici le mail de 1000Mercis : "Nous avons eu la semaine dernière un souci avec l'email automatique relance filleul J+15 : un filleul a été saisi (par deux parrains différents : pas d'effet Parkinson) deux fois à moins d'1h d'intervalle. extrait de la table sponsorship correspondant : sponsorship_id creation_date change_date spo_status_code spo_typ_code parent_account_id child_account_id 148611147 2007-08-17 17:00:28.000 2007-08-17 17:07:40.000 20 20 14676164 14744509 148611322 2007-08-17 16:36:01.000 2007-08-17 17:07:16.000 20 20 11673158 14743678 extrait de la table user_account pour le filleul en question : user_account_id login usr_title_code first_name last_name email_address usr_type_code creation_date sponsorship_id 14743678 teamspirit1 10 colette braud kdxteam@hotmail.fr 10 2007-08-17 16:36:00.000 148611322 14744509 NULL NULL arno NULL kdxteam@hotmail.fr 40 2007-08-17 17:00:28.000 148611147 Il me semblait que ceci n'était pas possible, un individu ne pouvant pas être parrainé plus d'une fois par an ? La présence de doublons dans la cible provoquant le non envoi de l'email automatique, pourrais-tu me dire si ceci est un cas exceptionnel, ou un assouplissement de la règle qui doit nous conduire à revoir la procédure de ciblage automatique ? " Et voici la réponse d'Alexandre : "Ce cas n'aurait pas du arriver : lors d'un parrainage, si l'adresse mail est déjà dans la base, on tente de reparainner l'utilisateur si possible (inactif depuis plus de 12 mois, ...). Il semble donc y avoir un petit souci, un JIRA serait le bienvenue pour voir ça et essayer de trouver une solution. Petit historique : - 03/09/06-11:16 : A s'inscrit - 03/08/07-12:00 : A parraine B - 03/08/07-12:35 : B s'inscrit - 17/08/07-16:36 : A parraine C - 17/08/07-16:54 : C s'inscrit - 17/08/07-17:00 : B parraine C' (au lieu de se faire jeter à tenter de parrainer C) (Remarque : entre B et C : chacun possède comme pseudo le mot de passe de l'autre ...) " Merci:-) Agathe |
| Commentaires |
| Commentaire de Alexandre Garnier [ 11/sept./07 15:36 ] |
|
select * from spo_event where sponsorship_id in (148611147,148611322); SPO_EVENT_ID SPONSORSHIP_ID CREATION_DATE SPE_TYPE_CODE ------------------------------------------------------------------------------------------------------------------------- 2525929 148611322 17/08/2007 16:36:01 10 2525994 148611322 17/08/2007 17:07:16 20 2525980 148611147 17/08/2007 17:00:28 10 2526029 148611147 17/08/2007 17:07:40 20 |
| Commentaire de Alexandre Garnier [ 20/sept./07 18:56 ] |
| Cas tordu qui ne doit quasiment jamais arriver, faudrait se pencher dessus pour voir. |
| Commentaire de Fabrice Feugas [ 19/janv./10 16:34 ] |
| Toujours d'actualité ? On a pu reproduire ? Si non, won't fix... |
| Commentaire de Fabrice Feugas [ 17/févr./10 12:16 ] |
|
A noter : on va réduire la période de gel des filleuls de 12
à 3 mois. Les gens seront donc "reparrainables" au bout de 3 mois, y
compris ceux qui se sont inscrits d'eux-même mais qui n'ont fait aucune
action sur le site. De même, suite à cette modification il y a toute un lot de parrainage que nous allons faire expirer (ceux qui auront une date de création supérieure à 3 mois) et qui seront reparrainables. On en reparlera avec BI pour maitriser les impacts de ces modifications. |
| Commentaire de Fabrice Feugas [ 08/avr./10 10:01 ] |
| Sous contrôle d'Alexandre, on a traité ce problème dans le cadre du projet parrainage lot 1. |
[Finance] : Adaptation fonctionnelle de la gestion de la TVA pour les rapports BI pour les PLF rance et Espagne
(BIN-273)
|
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Finance |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Sub-improvement | Priorité: | Majeur |
| Rapporteur: | Claudie Dufresne | Attribution: | Romain Czornomaz |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Description |
|
Agathe, Dans le cadre des déclarations mensuelles de TVA notamment, nous devons pouvoir justifier les montants déclarés en exonération de TVA tant sur les transactions du site Français que sur celles du site Espagnol. Il faudrait donc mettre en place une requête permettant d'obtenir l'ensemble des transactions exonérées de TVA pour le mois écoulé avec les informations suivantes : - les mêmes que sur l'extraction du mois de mars (item id - seller account - payment contry - compensation country - expedition country - seller type - product type - n° intracom - VAT Rate) - avec en plus une colonne mentionnant le montant (HT) de la transaction N'hésite pas si tu as besoin d'information complémentaire ou explication Merci claudie |
| Commentaires |
| Commentaire de Agathe Remy [ 14/mai/07 10:54 ] |
|
Romain, Peux-tu commencer les spécifications fonctionnelles? Merci:-) Agathe |
| Commentaire de Romain Czornomaz [ 27/juil./07 16:00 ] |
|
Claudie, Le rapport "Captured VAT exempted items by authorization month" a été déployé en france et en l'espagne sur la plateforme BI. Peux tu valider les rapports et cloturer la demande? Merci d'avance, Romain |
| Commentaire de Claudie Dufresne [ 30/juil./07 14:48 ] |
|
Romain, j'ai fait le test sur la période de juin, c'est ok. Juste une petite remarque, est-il possible de rajouter un total sur la colonne "Commission net" merci à toi claudie |
| Commentaire de Romain Czornomaz [ 30/juil./07 15:08 ] |
|
Claudie, Les modifications sont faites :) Le total sur la colonne "comission net" est present sur les 2 rapports France et Espagne. Bonne journée, Romain |
| Commentaire de Claudie Dufresne [ 30/juil./07 16:28 ] |
|
Tout est ok pour moi, merci à toi Romain ! |
| Commentaire de Claudie Dufresne [ 26/oct./07 14:10 ] |
|
Agathe, Romain, Pouvez-vous relancer la requete pour nous permettre de connaitre les vendeurs pro "CEE" qui n'auraient toujours pas renseigné de numéro intracommunautaire. merci à vous claudie |
| Commentaire de Romain Czornomaz [ 23/nov./07 12:26 ] |
|
Claudie, Je ferme la demande, je 'tai envoyé le 26Oct la liste des vendeurs exemptés de TVA pour la France et l'Espagne. tu pourras la réouvrir pour avoir la liste à jour. Bonne journée, Romain |
[APP-16778] demande code velocity pour surveiller nombre d'annonces dans une catégorie. Création: 22/juin/07 15:47 Mise à jour: 31/juil./07 19:28 Résolue: 20/juil./07 09:56 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 14.2.1 |
| Version(s) corrigée(s): | 16.0.0 |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Cedric Favero | Attribution: | Geneviève Beaujard |
| Résolution: | Aucune correction envisagée | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Classif1: | BO |
| Classif2: | fraude |
| Description |
|
Toujours en raison des problèmatiques de contrefaçon , il
nous faudrait pouvoir avoir la possiblité de detecter les utilisateurs
qui ont plus d'un certain nombre d'annonces dans une catégorie donnée. Actuellement on peut detecter par la profondeur de stock: ex: $advert.availableCount.intValue() > 5 (pour une profondeur de stock superieure à 5) Mais celà ne permet de detecter que ceux qui ont une quantité supérieure à 5 sur une meme annonce. Il nous faudrait pouvoir detecter ceux qui ont plus de X annonces dans une certaine catégorie: ex: plus de 10 annonces dans la rubrique parfums ou maroquinerie Quel serait le code correspondant pour cette fonctionnalité? Merci. |
| Commentaires |
| Commentaire de Cedric Favero [ 22/juin/07 15:49 ] |
|
Dans le meme esprit , est-il possible de detecter un comportement comme suit? : tel vendeur a vendu plus de x produits de telle catégorie dans tel délai. ex: utilisateur a vendu plus de 20 parfums dans les 6 derniers mois. |
| Commentaire de Edouard Gomez-Vaez [ 17/juil./07 09:10 ] |
| Geneviève, peut-être avons nous déjà l'info à dispo, alors nous pourrons la mettre dans le contexte si elle n'y est pas. Sinon, on regarde ensemble. |
| Commentaire de Geneviève Beaujard [ 20/juil./07 09:56 ] |
| Desolé cher cedric, mais ce que tu demandes releve plus du BI. |
| Commentaire de Cedric Favero [ 20/juil./07 09:58 ] |
|
Merci on s'y interessera donc un peu plus tard par l'intermédiaire de Business Objects. |
[APP-16863] relance coupon alors qu'utilisateur a déjà acheté Création: 29/juin/07 16:29 Mise à jour: 13/janv./09 11:41 Résolue: 20/sept./07 16:24 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Mails |
| Affecte la/les version(s): | 14.2.1 |
| Version(s) corrigée(s): | 38.0.0 (TX-D Bis) |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Cedric Favero | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM: | *** RESERVE *** |
| Classif1: | MON COMPTE |
| Classif2: | coupon |
| Description |
|
Pseudo: jpds110 On lui envoie le 29/06 un message: "Rappel : votre bon cadeau de 6 euros est toujours valable ! De: "PriceMinister" <news@newsletter-priceminister.com> Ajouter au carnet d'adresses Yahoo! DomainKeys a confirmé que ce message a été envoyé par newsletter-priceminister.com. En savoir plus À:..." Pb : il a déjà acheté le 14/06! Comment se fait-il qu'on envoie ce type de relance? |
| Commentaires |
| Commentaire de Renaud Dierickx [ 05/sept./07 09:51 ] |
|
Je ne trouve pas ce mail dans l'api... C'est un mail envoyé par le BI / Marketing ? Pouvez-vous me le confirmer ? Merci. |
| Commentaire de Agathe Remy [ 05/sept./07 10:10 ] |
|
En effet, ce mail est une campagnes réflexe Marketing envoyée par 1000Mercis. Il faut remonter cela à Alexandra : a priori il y a un pb dans les ciblages faits par 1000Mercis. D'un autre côté, entre le 15 et le 30 juin, il y a eu la migration technique des bases de données PM qui nous a forcé à suspendre la mise à jour des données chez nos partenaires. Peut-être que ce ciblage erroné en est un impact??? Cédric, as-tu d'autres exemples de ce type à une autre période? Pour info, ce mail fait partie d'une série de 4 mails envoyés aux nouveaux inscrits non acheteurs. Le 1er mail est envoyé si un inscrit n'a pas acheté sur PM 45 jours après son inscription, les autres mails étant des relances à 15j, 30j, puis 45j suivant. Et je viens de retrouver un mail du 30/04/2007 d'Odile prévenant Steven et Claire. Peut-on fermer ce JIRA? Merci:-) Cordialement, Agathe |
| Commentaire de Cedric Favero [ 19/sept./07 16:36 ] |
|
je n'ai pas d'autre cas similaires à signaler. On peut fermer le JIRA.. |
[BIN-420] [LRO] : Nombre de vendeurs/nouvelles ventes emailing La Redoute Occasion Création: 28/févr./08 10:11 Mise à jour: 14/mai/09 17:00 Résolue: 10/juin/08 17:19 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Partners |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Aurélie Maccario | Attribution: | Florian Ambrosi |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
la redoute tracking emailing1.xls
la redoute.xls
|
||||||||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Description |
|
Bonjour, Nous aimerions construire un rapport qui nous permette de mesurer le nombre de nouvelles mises en vente et de nouveaux vendeurs suite à l'envoi d'un mailing pour La Redoute par Redoute sur tous les contacts La Redoute Occasion. Ce mailing est tracké Opération LaRedoute Occasion dans "tracking 1" (et non le tracking du brand). Est-ce possible ? Merci Aurélie |
| Commentaires |
| Commentaire de Agathe Remy [ 28/févr./08 10:59 ] |
|
Bonjour Aurélie, Pourrais-tu préciser : - le contexte - l'objectif - l'impact business attendu - l'urgence de la demande ? Merci. Agathe |
| Commentaire de Aurélie Maccario [ 28/févr./08 11:39 ] |
|
Bonjour Agathe, Il s'agit en fait d'une newsletter qui a été envoyée en février aux contacts de La Redoute Occasions. Elle n'était pas orientée "promotion" mais plutôt "vente" (pousser les abonnés à vendre des articles). Afin de voir si le message a bien fonctionné, nous souhaitons connaître le nombre de nouveaux vendeurs suite à cette news pour faire un bilan à La Redoute. Cela nous servira donc pour les prochaines news que nous allons envoyées. Nous souhaiterions faire un retour à La Redoute dans la journée. Je reste à ta disposition si tu as besoin d'autres précisions. Merci. Aurélie |
| Commentaire de Agathe Remy [ 28/févr./08 12:02 ] |
|
Dans la journée me parait un délai plus qu'illusoire... Nous pouvons te proposer de fournir ces données la semaine prochaine. Est-ce que cela te convient ou bien annulons-nous la demande? Merci. Agathe |
| Commentaire de Aurélie Maccario [ 28/févr./08 12:09 ] |
|
Agathe, Je suis désolée, je suis nouvelle je ne savais pas qu'il y avait un planning assez chargé. La semaine prochaine serait parfait. Merci beaucoup pour tes réponses rapides. Aurélie |
| Commentaire de Florian Ambrosi [ 04/mars/08 17:30 ] |
|
Aurélie, Je te joint un fichier Excel répondant à ta demande. Si tu as des questions, je suis à ta dispo. Florian. |
| Commentaire de Florian Ambrosi [ 05/mars/08 11:23 ] |
|
Aurélie, Comme vu ce matin, je te joint le fichier avec seulement le tracking emailing1 de la redoute occasion. Désolé pour la confusion. Florian. |
| Commentaire de Florian Ambrosi [ 05/mars/08 18:05 ] |
|
Agathe, Peux-tu valider le rapport "Public Folder/Développement/Advert/", ainsi que les specs "V:\Reporting\BusinessIntelligence\En Développement\2008-02 followup sales newsletter"? Merci. Florian |
| Commentaire de Thomas Beylot [ 06/mars/08 11:22 ] |
|
Bonjour je me permet d'intervenir dans ce jira suite à discussion avec Agathe lundi. En effet je pense qu'il faudrait peut être mieux préciser la demande pour éventuellement en faire un rapport que l'équipe marketing dans son ensemble pourrait utiliser non ? Souhaitez vous un brief plus précis ? merci Thomas |
| Commentaire de Ghislain Gridel [ 17/mars/08 14:19 ] |
| oui. Merci Thomas. |
| Commentaire de Thomas Beylot [ 14/mai/08 18:02 ] |
|
Salut de retour après une longue absence sur le sujet, je voulais savoir si au delà des deux rapports attachés en pj (qui ont l'air bien) on avait la possibilité de tester le rapport sur Bi ? > peut-on choisir le groupe de tracking et/ou tracking name > peut-on avoir les catégories de mise en vente associées ? thomas. |
| Commentaire de Florian Ambrosi [ 26/mai/08 14:07 ] |
|
Agathe, C'est passé en production en France et en Espagne. Florian |
| Commentaire de Agathe Remy [ 10/juin/08 15:51 ] |
|
Agathe, Pour le rapport de ce matin (nombre de vente par rapport à un code de tracking) quand je génère le rapport pour la news LRO il est nul alors que nous avons envoyé une news le 18 mai. Le tracking est LRO_emailing_mai. Est-ce que Florian aurait le temps d'y jeter un coup d'¿il ? Dois-je fais un JIRA ? Merci par avance pour ton retour et bonne journée. -- Aurélie Maccario www.PriceMinister.com Tél : 01 42 78 83 96 |
| Commentaire de Florian Ambrosi [ 10/juin/08 17:19 ] |
|
Le problème est normalement résolu. Le rapport est déployé en France et en Espagne. Florian |
| Commentaire de Aurélie Maccario [ 10/juin/08 17:27 ] |
|
Ok super ça marche maintenant. Merci beaucoup et bonne fin de journée ! Aurélie |
[PMV : Migration des Anciens Vendeurs]
(APP-21971)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | 27.0.1 |
| Version(s) corrigée(s): | 31.0.0 (TX-C) |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | Arnaud Forgues | Attribution: | Arnaud Forgues |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Projets PM archivés: | Paiement - Migration anciens vendeurs |
| Description |
|
Dans ce lot, on migre les utilisateurs particuliers
actuellement en privilège SILVER (virement) dont le PMV n'est pas encore
activé (sauf les vendeurs -2, qui par construction auront déjà été
migrés dans le lot 1) en privilège Platine mode libre sans configuration
des reversement du PMV. Ces utilisateurs seront soumis à une communication par mail des changements liés à cette migration : en effet, ils devront activer leur PMV puis configurer une demande de reversement ponctuelle ou régulière par virement afin de recevoir à nouveau les paiements de leurs ventes. |
| Commentaires |
| Commentaire de Arnaud Forgues [ 02/oct./08 15:28 ] |
|
La migration est effective. Le ciblage est en cours au BI et le mailing d'accompagnement sera envoyé samedi prochain. |
[BIN-482] [Finance] : Nouveau rapport "seller bonus" Création: 05/sept./08 16:07 Mise à jour: 23/oct./09 10:15 Résolue: 19/oct./09 16:57 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Finance |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Claudie Dufresne | Attribution: | Julien Girardet |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Description |
|
Agathe, Dalila, Toujours dans le cadre de la justification de la dette vendeur, il reste un rapport à créer. Il s'agit de pouvoir justifier le solde des SELLER BONUS à payer à la fin d'une période. Comme pour le rapport "seller credit", il faudrait créer le rapport sur la base de la date "claim closing date" et reprenant les info suivantes : item id, seller login, authorization date, claim closing date, claim status, ... Du fait du volume important sur la France, il serait je pense nécessaire, comme pour le seller credit, d'ouvrir deux rapports : seller bonus summary seller bonus détaillé A votre disposition si vous avez besoin d'info complémentaires ou précisions. claudie |
| Commentaires |
| Commentaire de Dalila Belkebir [ 19/oct./09 16:57 ] |
|
Bonjour, Deux nouveaux rapports sont maintenant disponibles dans le BI : ¿ Seller bonus summary by claim closing date ¿ Seller bonus by claim closing date and authorization month Ces rapport a pour objectif de permettre la justification du solde des SELLER BONUS à payer à la fin d'une période. Il sont disponibles : - Dans le repertoire Financial/Accouting visible par l'équipe DAF uniquement - Sur chacune des plateformes : France, SPAIN & UK ! Lors de la réalisation de spécifications nous avons marginalisé des transactions avec des réclamations avec bonus et en statut « rejected ». Ces transactions permettent de justifier l'écart de 26.7¿ sur la France : ITEM ID SELLER BONUS STATUS AUTHORIZATION_DATE 1416609 5 rejected 06/10/2002 1422183 1,7 rejected 07/10/2002 1720358 20 rejected 15/11/2002 Total 26,7 Merci de nous faire part de vos retours pour validation du JIRA. Cordialement, Dalila. 57, boulevard de la Villette 75010 Paris - France Tel :01.42.78.97.49 |
| Commentaire de Dalila Belkebir [ 23/oct./09 10:15 ] |
|
Validé par Claudie le 23/10. De : Claudie Dufresne [mailto:claudie.dufresne@priceminister.com] Envoyé : vendredi 23 octobre 2009 10:08 À : 'Julien Girardet' Cc : philippe.favrot@priceminister.com; 'samira remila'; 'Dalila Belkebir' Objet : RE: [JIRA] Résolue: ( Importance : Haute Bonjour Julien Tout est ok pour moi ! c'est top ! Un rapport de plus qui nous sera bien utile ! Merci bcq à toi claudie Dalila. |
[APP-22032] [CO MARKET] Opération SFR EEEPC Création: 05/sept./08 11:53 Mise à jour: 16/sept./08 14:43 Résolue: 16/sept./08 12:16 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 28.0.2.1 |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Benjamin Guerville | Attribution: | Olga Costa |
| Résolution: | Corrigé | ||
| Σ Estimation restante: | Non spécifié | Estimation restante: | Non spécifié |
| Σ Temps consacré: | Non spécifié | Temps consacré: | Non spécifié |
| Σ Estimation originale: | Non spécifié | Estimation originale: | Non spécifié |
| Pièces jointes: |
Portables1000.fla
Portables1000.swf
priceminister.swf
|
||||||||||
| Sous-tâches: |
|
||||||||||
| Pays: |
FRA - France
|
||||||||||
| Projets PM: | *** A PLANIFIER *** |
| Description |
|
Bonjour, Nous avons eu le GO de la régie. L'idée est donc de mettre en ligne l'opération au plus vite et pour 3 semaines. Il y a 3 points : - Mise en place d'un lien "xxx" dans le menu déroulant bleu Informatique (tout en bas) - Mise en place d'un lien "xxx" dans la npf informatique (en bas à droite". - Création d'une page IG accessible depuis ces liens et hébergeant une créa SFR. Il manque encore : - Le wording des liens "xxx" - L'url de la créa Je reviens vers vous au plus vite. Merci de votre coopération ! Benjamin |
| Commentaires |
| Commentaire de Benjamin Guerville [ 05/sept./08 14:08 ] |
|
Serait-il possible que vous me communiquiez l'url de la page IG même si celle-ci n'est pas encore crée ? ça pourrait être par exemple : http://www.priceminister.com/info/no/op/SFR merci BG |
| Commentaire de Olga Costa [ 05/sept./08 14:08 ] |
|
Bonjour Thomas il faut que j'ai les éléments aujourd'hui. Merci |
| Commentaire de Benjamin Guerville [ 05/sept./08 14:41 ] |
| Merci de penser à mettre un tag XITI sur la page IG. |
| Commentaire de Benjamin Guerville [ 05/sept./08 15:59 ] |
|
Il serait aussi intéressant de pouvoir suivre le nombre de
clic sur chacun des liens, par le biais de 2 tracking différents par
exemple. Merci |
| Commentaire de Olga Costa [ 05/sept./08 16:34 ] |
| http://www.priceminister.com/info/no/op/sfr c'est mieux avec les minuscule |
| Commentaire de Olga Costa [ 08/sept./08 10:25 ] |
|
Bonjour Benjamin, Est ce que tu as les éléments? Merci Olga |
| Commentaire de Olga Costa [ 09/sept./08 11:36 ] |
|
Benjamin, je passe ce jira en v28.0.0.1 Merci |
| Commentaire de Benjamin Guerville [ 09/sept./08 12:34 ] |
|
Voici les éléments en Flash. J'aurais le wording des liens texte d'ici peu. Merci |
| Commentaire de Benjamin Guerville [ 09/sept./08 12:56 ] |
|
Autres points : - la flash fait 1000px de large : ok pour moi et validé avec Christophe et Swan (exceptionnelement compte tenu du contexte) - la page ne doit pas être référencée, brouillage des liens. Merci |
| Commentaire de Olga Costa [ 09/sept./08 15:55 ] |
|
http://bo.pm.bollinger:3180/info/no/op/sfr voila la page |
| Commentaire de Benjamin Guerville [ 09/sept./08 16:37 ] |
|
Voici le texte à utiliser sur le lien texte pour l'opération
SFR - EEEPC (lien menu bleu, lien npf et nom de la page) : "EeePC : c'est Internet partout" Le lien à utiliser pour les command clic est : http://www.smartadserver.com/call/cliccommand/1698506/[timestamp]? Merci ! |
| Commentaire de Olga Costa [ 10/sept./08 14:03 ] |
|
Contenu publié Fabien feras le liens |
| Commentaire de Benjamin Guerville [ 10/sept./08 15:06 ] |
|
Hello, Date de fin de l'opé : 04/10/2008 Merci |
| Commentaire de Fabien Farache [ 10/sept./08 18:22 ] |
| Mis en place... puis enlevé, suite à la demande de BEG |
| Commentaire de Benjamin Guerville [ 15/sept./08 10:01 ] |
|
Bonjour, En pièce jointe, la nouvelle créa du partenaire. Elle remplace l'ancienne. Une fois la créa mise en place, merci de réactiver les liens. Merci à tous ! BG |
| Commentaire de Benjamin Guerville [ 15/sept./08 17:41 ] |
|
Je reviens vers vous au sujet du clic command, en fait il s'agit d'utiliser l'url : http://www.smartadserver.com/call/cliccommand/1698506/[timestamp]? à la place de : http://www.priceminister.com/info/no/op/sfr afin que la régie puisse compter les clics. Est-ce ok pour vous ? Si mise en ligne mercredi 17, nouvelle date de fin d'opé : 09/10/2008 Merci |
[BIN-502] [Kpi mev] : Création d'un rapport de suivi des créations de fiches produits en Front Office Création: 22/oct./08 10:00 Mise à jour: 01/déc./08 09:52 Résolue: 01/déc./08 09:52 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Nouvelle fonctionnalité | Priorité: | Majeur |
| Rapporteur: | Agathe Remy | Attribution: | Dalila Belkebir |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
DMR - KPI MEV.doc
|
| Pays: |
FRA - France
|
| Description |
|
Contexte : Le pôle catalogue a modifié le process de mise en vente avec création de fiche produit en déplaçant la connexion/création de compte à la fin du process. L'objectif de ce projet était d'augmenter le nombre de mev avec création de FP en partant de l'hypothèse que la connexion/création de compte représentait un frein important pour l'internaute et qu'en la déplaçant à la fin du process, celui-ci ayant déjà rempli toutes les étapes de la mev, ce frein serait atténué. Afin de mesurer l'impact de ce projet, nous voulons mettre en place un rapport quick win permettant de : - mesurer l'augmentation des créations de fiches produits en Front Office (donc hors imports) dans le temps (le projet a été livré en Production le 18/09/2008). - comparer ce nombre de fiches produits au nombre total d'annonces créées afin d'évaluer si cette augmentation est uniquement liée à celle de l'activité ou bien également à la livraison du projet. A voir s'il est pertinent de suivre ces indcateurs par familles/types de produits. Dans le cas de la mev avec création de FP, le nombre de d'annonces créées est égal au nombre de FP créées. Agathe |
| Commentaires |
| Commentaire de Dalila Belkebir [ 30/oct./08 19:16 ] |
|
Benoit, Agathe, J'ai chargé les spécifications des rapports à mettre en place (un par famille de produits et un autre par type de produits). Merci de me faire part de vos retours ou validation pour implémentation. Dalila. |
| Commentaire de Thomas Beylot [ 31/oct./08 18:51 ] |
|
hello je me permets d'intervenir dans ce jira pour préciser qu'à mon avis des kpi qui n'utiliseraient que bi ne seraient pas super pertinents... il faudrait utiliser xiti et comparer le tunnel de mev avant/après et observer la fuite (ou pas) des visiteurs. thomas |
[DEC-630] [PMV - Migration des Anciens Vendeurs] : extraction des cibles pour le mailing Création: 18/sept./08 19:07 Mise à jour: 15/oct./08 09:54 Résolue: 15/oct./08 09:54 |
|
| Etat: | Fermé |
| Projet: | Reporting |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Agathe Remy | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ESP - Espagne, FRA - France
|
| Description |
|
Dans le cadre de la migration des anciens vendeurs en
privilège Platine, il s'agit de réaliser les extractions de cibles pour
les mailings d'accompagnement. - 3 lots : 1) Vendeurs Particuliers par Chèque 2) Vendeurs Particuliers par virement dont le PMV est activé 3) Vendeurs particuliers par Virement dont le PMV n'est pas activé - 1 mail par lot avec 2 versions => 2 extractions par lot 1 version Price 1 version Brand Le 1er mail doit être envoyé le 25/09 et concerne les vendeurs payés par chèque qui seront migrés le 23/09. Les extractions devront donc être fournies à 1M le 24/09. Le 2ème mail est prévu le 04/10 et concerne les vendeurs payés par virement dont le PMV est activé et dont la migration est prévue le 01/10. Les extractions devront donc être fournies à 1M le 03/10 au plus tard. Le 3ème mail est prévu le 13/10 et concerne les vendeurs payés par virement dont le PMV n'est pas activé et dont la migration est prévue le 10/10 => problème puisque le 10 est un vendredi et le 13 un lundi... Les informations à fournir sont : pseudo et email pour le fichier PM pseudo, email, brand name et brand url pour le fichier Cobranding |
| Commentaires |
| Commentaire de Agathe Remy [ 18/sept./08 19:08 ] |
|
Concernant les critères de ciblage de ce lot n°4, je confirme donc au BI les infos suivantes : => Baser la cible sur l'événement dans USR_EVENT avec - use_type_code = 900 (WALLET_CONFIG_UPDATE) - description LIKE 'Migration en mode platine Lot 4%' - creation_date > TO_DATE('22/09/2008', 'DD/MM/YYYY') Pour les lots 5 et 6 qui auront lieu le 1er puis le 10 octobre, ce sera la même chose en remplacant : - « Lot4 » par « Lot 5 » ou « Lot 6 » - La date de creation Pour les infos brand, on aura donc : - Le nom du brand  « brand_name » de la table « brand » - L'url de la HP du brand IF brand.host IS NULL THEN brand.alias || 'priceminister.com' ELSE brand.host END IF; A noter qu'on ne devrait pas avoir de cobrand pour l'envoi en Espagne, sauf peut etre les www et bo à considérer comme www ? Voilou, Arnaud Forgues |
| Commentaire de Agathe Remy [ 15/oct./08 09:54 ] |
|
C'est fini! Youpi:-) Agathe |
[IMP-3506] problèmes de caractères accentués: livre-revue Création: 08/avr./09 10:12 Mise à jour: 30/oct./09 15:51 Résolue: 27/avr./09 09:50 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Anne Korchia | Attribution: | Frédéric Nahum |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Fichier livre-revue.zip
|
| Pays: |
FRA - France
|
| Login: | livre-revue |
| Séparateur: | N/A |
| Type de traitement: |
N/A
|
| Description |
|
problèmes de caractères accentués : ceux ci ne passent pas
correctement sur le site (à la place des é, è, ê ou autre j'ai des
hiéroglyphes). Je pense que c'est parceque je travaille et gère ma base
de données depuis un oridnateur sous Mac OS. Pourriez vous, pour faire
simple, paramétrer mes imports de base de données strictement comme ceux
du compte bpettit (mail : librairie.pettit@noos.fr), que je gère également depuis le même ordinateur avec le même OS, et qui ne pose aucun problème avec les caractères accentués |
| Commentaires |
| Commentaire de Frédéric Nahum [ 08/avr./09 18:22 ] |
| Le format est pourtant déja parmétré pour mac c'est bizarre il doit avoir a la base déja un problème avec son fichier, demande lui de t'envouer son fichier directement par mail pour qu'on puisse l'analyser en direct |
| Commentaire de michalon [ 08/avr./09 18:41 ] |
|
la version brut (directement issue de mon mac (Mac OS
10.5.6), enregistrée au format txt) et la version retraitée en UFT8 par
le biais du logiciel TextEdit (cette fonction permet de corriger les
problèmes d'accent sur mon autre compte : bpettit ; mais pas sur ce
compte livre-revue, donc) |
| Commentaire de michalon [ 15/avr./09 14:39 ] |
|
salut où en est la demande? merci |
| Commentaire de michalon [ 21/avr./09 15:32 ] |
|
salut où en est la demande? merci |
| Commentaire de Frédéric Nahum [ 27/avr./09 09:50 ] |
| c'est fait il faut donc a l'avenir que le pro nous envoi sont fichier en UTF8 |
[APP-24124] Utilisation incorrecte des adresses sources dans les mails de parrainage Création: 02/févr./09 18:02 Mise à jour: 12/juin/09 15:45 Résolue: 11/juin/09 12:19 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Mails, Parrainage |
| Affecte la/les version(s): | 39.0.0 (CTN-I) |
| Version(s) corrigée(s): | 48.0.0 (CTN-L) |
| Type: | Amélioration | Priorité: | Bloquant |
| Rapporteur: | Patrice Boulanger | Attribution: | Damien Dorizy |
| Résolution: | Corrigé | ||
| Σ Estimation restante: | Non spécifié | Estimation restante: | Non spécifié |
| Σ Temps consacré: | Non spécifié | Temps consacré: | Non spécifié |
| Σ Estimation originale: | Non spécifié | Estimation originale: | Non spécifié |
| Pièces jointes: |
app24124.JPG
|
|||||||||||||||
| Sous-tâches: |
|
|||||||||||||||
| Pays: |
ALL - Tous
|
|||||||||||||||
| Site: | Prod | |||||||||||||||
| Projets PM: | *** RESERVE *** | |||||||||||||||
| Classif FONC: | tech |
| Description |
|
Beaucoup de mails de parrainage sont rejetés par les relais
de messagerie car le paramétrage de ces courriers n'est pas valide. En effet, on forge (rien à voir avec Arnaud) l'adresse de l'émetteur à partir du compte du parrain. Or, plusieurs mécanismes, et en particulier SPF (Sender Policy Framework) sont exactement fait pour empêcher ce type de manipulation. Illustration par les logs de graces: Feb 2 04:18:33 graces00 postfix/smtpd[7241]: 1E14814220: client=hercule02.atlantide.jmsp.net[10.150.28.77] Feb 2 04:18:33 graces00 postfix/cleanup[7242]: 1E14814220: message-id=<19815760.1233544713120.JavaMail.nobody@nosuchhost.nosuchdomain.com> Feb 2 04:18:33 graces00 postfix/cleanup[7242]: 1E14814220: warning: header Subject: AUDERAVASSON, voici 7 Euros offerts de la part de reuse from hercule02.atlantide.jmsp.net[10.150.28.77]; from=<couzen4@hotmail.fr> to=<marieano@hotmail.fr> proto=ESMTP helo=<hercule> Feb 2 04:18:33 graces00 postfix/nqmgr[28793]: 1E14814220: from=<couzen4@hotmail.fr>, size=22664, nrcpt=1 (queue active) Feb 2 04:18:34 graces00 postfix/smtp[6341]: 1E14814220: to=<marieano@hotmail.fr>, relay=mx2.hotmail.com[65.54.244.40], delay=1, status=sent (250 mail from IP 212.23.167.26 soft failed sender ID check. Please ensure this IP is authorized to send mail on behalf of [hotmail.fr]) Feb 2 04:18:34 graces00 postfix/nqmgr[28793]: 1E14814220: removed A noter le message du relais: sent (250 mail from IP 212.23.167.26 soft failed sender ID check. Please ensure this IP is authorized to send mail on behalf of [hotmail.fr]) En clair: - on ne peut le détecter car le relais répond 250, donc OK en gros - très peu de chance que le message ne soit délivré au(x) destinataire(s) par la suite. - risque de perdre de plus en plus de mails de parrainage si d'autres gros domaines paramètrent SPF dans leur DNS Il faut donc changer la façon de construire ces mails applicatifs. |
| Commentaires |
| Commentaire de Patrice Boulanger [ 02/févr./09 18:27 ] |
|
Mes préconisations pour la construction de ces emails: Return-Path: indique à quelle adresse doivent être envoyées les réponses automatiques du serveur (no delivery par exemple) valeur: mailer@priceminister.com Reply-To: indique l'adresse à laquelle une réponse éventuelle du destinataire va être envoyé (quand on clique sur Répondre dans outlook par exemple). valeur: devrait être une adresse en priceminister.com => BO ? From: ce qui apparaîtra si on regarde le mail avec Outlook ou un webmail. Le format devrait être: "Prénom Nom" <mailer@priceminister.com> avec "Prénom Nom" qui peut être ce que vous voulez. Merci. Patrice. |
| Commentaire de Justin Ziegler [ 02/févr./09 18:45 ] |
| ne peut on mettre l'adresse email du parrain dans le "reply-to" ? |
| Commentaire de Fabrice Feugas [ 03/févr./09 11:12 ] |
| N'y avait-il pas une valeur juridique dans le fait que le filleul doit recevoir l'email parrainage en provenance de l'adresse email de son parrain (parrain@hotmail.fr par exemple) et non d'une adresse @priceminister.com ? |
| Commentaire de Justin Ziegler [ 03/févr./09 11:26 ] |
|
Non, c'était une volonté marketing. On pensait que c'était mieux ! (on n'avait pas de juriste à l'époque) |
| Commentaire de Fabrice Feugas [ 03/févr./09 14:49 ] |
| Ok donc vraiment pas de contre-indication à cette modification. Patrice, est-ce que tu penses que les SPF nous bloqueront si on met l'email parrain dans le "reply-to" ? |
| Commentaire de Justin Ziegler [ 03/févr./09 15:02 ] |
|
Un peu de doc : http://idunno.org/archive/2004/10/18/133.aspx |
| Commentaire de Benoit Tabaka [ 03/févr./09 16:05 ] |
|
Sur le plan juridique, pas bloquant. La CNIL demande uniquement que le nom du parrain (expéditeur) soit clairement mentionnée (le mieux dans l'entête du message, comme expéditeur) mais la CNIL ne demande pas pour autant que l'adresse mail du parrain apparaisse. |
| Commentaire de Cedric Favero [ 03/févr./09 17:15 ] |
|
Sauf qu'avec mailer@priceminister.com
, on a plein de problemes de blacklisting (ex hotmail pour lesquels
des utilisateur ne recoivent plus aucun mail de notre part). =>
Plutot utiliser nepasrepondre@priceminister.com Et que donner l'adresse email du parrain , c'est pas génial niveau confidentialité, surtout dans le cas des parrainages Widget ou le filleul ne connait pas forcement son parrain. => Le parrain peut nous reprocher de communiquer ses informations personnelles. |
| Commentaire de Justin Ziegler [ 03/févr./09 17:27 ] |
|
1/ effectivement, on peut utiliser nepasrepondre@... plutot
que mailer, je pense aussi que c'est mieux (sauf s'il y a des raisons de
ne pas le faire). Au passage, on est justement en train de tenter de
résoudre le pb d'anti-spam sur hotmail, et celui ci ne vient peut etre
pas du mailer@... mais du return path et du from. 2/ on donne deja l'adresse du parrain, mais on le fait mal. Il s'agit de mieux le faire. 3/ Les widget parrainage ne sont pas concerné par les mails dont on parle ici. OK ? |
| Commentaire de Cedric Favero [ 03/févr./09 17:36 ] |
|
OK, si les widgets ne sont pas concernés c'est moins problematique. En tout cas le nepasrepondre@priceminister.com est à privilégier pour le Reply-To , car il délivre une information particuliere à la personne qui essaye de nous contacter par ce biais. |
| Commentaire de Fabrice Feugas [ 03/févr./09 17:55 ] |
|
En y réfléchissant, c'est vrai que ça me parait plus logique
d'affecter une adresse @priceminister.com au reply-to car étant donné
que l'utilisateur recevra un email de Price avec la charte price, s'il
fait "répondre" il s'attendra à nous répondre et pas à répondre à son
parrain. En revanche, ça semble pertinent d'indiquer le nom du parrain dans le from en précisant que c'est "via priceminister". En reprenant les indications de Patrice : "Prénom Nom via PriceMinister" <mailer@priceminister.com>. Oui les widgets parrainage ne sont pas concernés. |
| Commentaire de Swan Desportes [ 03/févr./09 18:03 ] |
|
Gestion des messages --> TX |
| Commentaire de Justin Ziegler [ 03/févr./09 19:40 ] |
|
Il y a une confusion. Pour moi on s'oriente vers : Return-Path: indique à quelle adresse doivent être envoyées les réponses automatiques du serveur (no delivery par exemple) valeur: nepasrepondre@priceminister.com Reply-To: indique l'adresse à laquelle une réponse éventuelle du destinataire va être envoyé (quand on clique sur Répondre dans outlook par exemple). valeur: l'adresse du parrain (sauf contre indication technique) From: ce qui apparaîtra si on regarde le mail avec Outlook ou un webmail. Le format devrait être: "Prénom Nom" <nepasrepondre@priceminister.com> avec "Prénom Nom" qui peut être ce que vous voulez. |
| Commentaire de Fabrice Feugas [ 04/févr./09 09:54 ] |
|
Oui, et ça ne risque pas d'être confusant pour l'utilisateur
de voir qu'il reçoit un email de PriceMinister et de répondre à
quelqu'un d'autre quand il fait "répondre" ? On peut imaginer que s'il voit du PriceMinister dans le from, s'il fait répondre, il pensera s'adresser à nous avec des questions pour le SAV... Si c'est le parrain qui reçoit ces questions, on met un intermédiaire en plus et on risque de brouiller les esprits. Au final c'est le SAV qui devra tout démêler. |
| Commentaire de Cedric Favero [ 04/févr./09 11:10 ] |
|
Pour moi le filleul n'a aucune raison de contacter le parrain en direct effectivement. S'il veut faire reply , il doit tomber sur nepasrépondre@priceminister.com qui va lui délivrer un message convivial et détaillé ;-) Par contre , pas de souci à faire apparaitre Prénom Nom via PriceMinister. |
| Commentaire de Justin Ziegler [ 04/févr./09 18:57 ] |
|
il y a parfois des parrains abusifs... je trouve que c'est potentiellement intéressant que le filleul puisse faire un reply au parrain pour lui dire "lache moi la grappe". en fait j'y vois meme une réduction du travail de l'équipe SAV qui n'auront donc pas à traiter ces cas. la limite, c'est que les gens risquent de s'insulter... et que du coup le SAV n'est pas mis au courant de l'abus qui concerne peut etre aussi d'autres filleuls. L'idéal pourrait être d'intégrer la notion de parrainage abusif en haut du mail de parrainage ? un truc du genre : "si vous ne connaissez pas xxxx_le_parrain : vous pouvez signaler un parrainage abusif" |
| Commentaire de Cedric Favero [ 04/févr./09 19:13 ] |
|
Mon idée en tant que paranoiaque du SAV , c'est éviter
qu'ils se contactent directement car on ne sait pas ce qu'ils peuvent
fabriquer. Toujours mieux qu'ils s'adressent à nous en cas de probleme. Si tu veux qu'ils puissent nous contacter en cas de souci, on les envoie vers page contact. |
| Commentaire de Justin Ziegler [ 04/févr./09 19:34 ] |
|
Bon, je retente la conclusion : Return-Path: indique à quelle adresse doivent être envoyées les réponses automatiques du serveur (no delivery par exemple) valeur: nepasrepondre@priceminister.com ==> risque de boucle de mail à cause de la config de reponse automatique ? Patrice ? Reply-To: indique l'adresse à laquelle une réponse éventuelle du destinataire va être envoyé (quand on clique sur Répondre dans outlook par exemple). valeur: nepasrepondre@priceminister.com From: ce qui apparaîtra si on regarde le mail avec Outlook ou un webmail. Le format devrait être: "Prénom Nom" <nepasrepondre@priceminister.com> avec "Prénom Nom" qui seront ceux du parrain ! on pourrait rajouter un "via PriceMinister" dans le from ? |
| Commentaire de Emeric Teil [ 01/avr./09 14:35 ] |
| Bloqué en attente de confirmation, cf. dernière commentaire de Justin... |
| Commentaire de Justin Ziegler [ 03/avr./09 18:13 ] |
| Patrice ? |
| Commentaire de Patrice Boulanger [ 07/mai/09 15:08 ] |
|
Voici la conclusion que je propose: - Return-Path: peut être fixé à ce qu'on veut, mais pas à nepasrepondre@priceminister.com. On pourrait mettre mailer@priceminister.com, ça ne devrait pas poser de problème côté antispam, puisque ce n'est pas une adresse From, c'est juste utilisé pour faire un retour en cas de problème avec la délivrance du mail. - Reply-To: nepasrepondre@priceminister.com pour qu'une éventuelle réponse du filleul reçoive un message convivial et détaillé (dixit Cédric Favero) - From: on peut tout imaginer dans la partie entre guillemet mais l'adresse devra être "nepasrepondre@priceminister.com" J'ai fait quelques tests, voici les résultat: [root@baillet ~]# telnet localhost 25 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. 220 vhq.babel.fr ESMTP 1.0 HELO tmp20 250 vhq.babel.fr MAIL FROM: mailer@priceminister.com 250 2.1.0 Ok RCPT TO: patrice.boulanger@priceminister.com 250 2.1.5 Ok DATA 354 End data with <CR><LF>.<CR><LF> From: "Le nom du parrain via PriceMinister" <nepasrepondre@priceminister.com> To: patrice.boulanger@priceminister.com Subject: Reply-To: tartanpion@priceminister.com Test. . 250 2.0.0 Ok: queued as 93B61648006 QUIT 221 2.0.0 Bye soit ici: Reply-To = tartanpion@priceminister.com From = "Le nom du parrain via PriceMinister" <nepasrepondre@priceminister.com> Voir la capture d'écran en copie pour le résultat. |
| Commentaire de Patrice Boulanger [ 07/mai/09 15:27 ] |
|
En fait, je pense qu'il serait souhaitable de pouvoir
modifier ces adresses facilement, par exemple en utilisant des
propriétés JBOSS. Ca serait mieux si on s'aperçoit qu'une adresse se
trouve blacklistée soudainement. Est-ce que c'est possible ? Patrice. |
| Commentaire de Nicolas Chauveau [ 07/mai/09 17:45 ] |
|
OK Sur le principe on défini 3 prop applicatives pour que l'exploitation puisse définir les valeurs - from - reply-to - return-path par défaut. TODO fonc : Vérifier si cela s'applique à tout type de mail (automatiques, BO ...) |
| Commentaire de Justin Ziegler [ 07/mai/09 17:49 ] |
|
non, cela ne s'applique pas directement à tout type de mail. on doit pouvoir positionner une valeur par défaut pour chaque paramètre applicable à tous les type de mail. (on lui donnera la valeur actuelle) en plus on veut pouvoir préciser une valeur spécifique d'un paramètre, type de mail par type de mail. |
| Commentaire de Cedric Favero [ 07/mai/09 17:50 ] |
|
Euh là on ne parle que des mails parrainage , n'est-ce pas? |
| Commentaire de Patrice Boulanger [ 14/mai/09 15:49 ] |
|
On ne parle en effet que des mails de parrainage. Qui plus
est, ce qu'il faut modifier est le comportement incorrect de
l'application lorsqu'elle envoie des mails de parrainage, ce n'est pas
le cas pour les autres mails applicatifs. En résumé: - 1 seule propriété pour le Return-Path. Personnellement, je pense que cette propriété pourrait être globale à tous les mails applicatifs - 1 propriété uniquement pour le parrainage qui va indiquer l'adresse utilisée dans le champ "From:" - Modifier l'appli pour qu'elle utilise la propriété ci-dessus dans les mails de parrainage pour le "From:" ("Prénom Nom via Priceminister" <l'adresse ci-dessus>) et la commande SMTP "MAIL FROM:". - Le champ "Reply-To:" n'est pas utile si on est d'accord que l'adresse utilisée pour une réponse manuelle de la part de l'utilisateur sera la même que pour le "From:", on pourrait donc le supprimer. |
| Commentaire de Nicolas Chauveau [ 28/mai/09 18:06 ] |
|
Cela devient critique pour le marketing (perte de vitesse du parrainage). cf OSZ. Voir avec PBO pour bien traiter le sujet. |
| Commentaire de Patrice Boulanger [ 09/juin/09 17:12 ] |
|
Salut le pôle contenu, Pour appuyer le dernier commentaire, pouvez-vous nous donner la planification pour la correction de ce bug? Merci. Patrice. |
| Commentaire de Fabrice Feugas [ 10/juin/09 14:08 ] |
| Pour reprendre la réponse faite par email, on est parti sur une mise en prod en CTN-L, la semaine prochaine. |
| Commentaire de Justin Ziegler [ 10/juin/09 14:45 ] |
|
voila une très bonne nouvelle ! pourrait on avoir un aperçu de la solution ? |
| Commentaire de Damien Dorizy [ 10/juin/09 19:00 ] |
|
La correction consiste à utiliser non plus l'email du
parrain, mais le mail utilisé par défaut dans le message type
correspondant. Par ailleurs, le nom de l'utilisateur est remplacé par un
label Infoglue : "Prénom Nom via PriceMinister". Pour le Return-Path, il sera défini dans le mail-service.xml. Ce qui donne : Return-Path : mailer@priceminister.com From : "Prénom Nom via PriceMinister" <nepasrepondre@priceminister.com> Reply-To : "Prénom Nom via PriceMinister" <nepasrepondre@priceminister.com> Plus d'infos dans le Wiki sur ce qui est fait et ce qu'il faudrait faire dans l'idéal : http://pricewiki.lan/Wiki.jsp?page=AdressesSourcesDesMails Le dév est fait, la solution devrait être opérationnelle en integ demain matin (jeudi 11/06). + des scripts restent à passer pour modifier le mail par défaut dans la table brand (voir |
| Commentaire de Damien Dorizy [ 11/juin/09 12:19 ] |
| C'est ok en integ |
| Commentaire de Justin Ziegler [ 11/juin/09 20:25 ] |
| si demain on souhaite changer cela, est ce que c'est paramétrable ? |
| Commentaire de Damien Dorizy [ 12/juin/09 09:05 ] |
|
Oui, pour les différents éléments : - L'adresse email du From et Reply-To est celle définie par les message-type parrainage en BO : il suffit donc de la changer en BO, et il est possible de la modifier pour un message en particulier. - Le label "Prénom Nom via PriceMinister" est défini dans Infoglue. - Le return-path est lui configuré de manière globale, modifiable par l'exploit mais pour tous les mails en même temps. |
[APP-23828] Surveillance vendeur - regle surveillant nbs de ventes committed par rapport aux ventes reçues Création: 02/janv./09 17:56 Mise à jour: 28/juil./09 15:44 Résolue: 21/juil./09 12:16 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 50.0.1 |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Cedric Favero | Attribution: | Dispatcher (Pôle TX) |
| Résolution: | Aucune correction envisagée | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
screenshot-1.jpg
|
| Pays: |
FRA - France
|
| Projets PM: | *** RESERVE *** |
| Description |
|
On a une règle de surveillance vendeur qui fait passer le
compte en visibilité -1 lorsque le compte a un nombre d'articles
committed >30 et 0 ventes reçues. Cette regle est actuellement "en dur" et non pas en mot-clé. La demande serait de savoir si on pouvait la "récupérer" en mot clé velocity afin de pouvoir la rendre plus flexible ? Celà nous permettrait de gérer plsu finement par type de produit et faire des exclusions. Merci. ex d'un compte ayant matché cette regle: http://bo.priceminister.jmh/user_back?action=userview&showeventothers=true&useraccountid=12978117 |
| Commentaires |
| Commentaire de Emeric Teil [ 26/janv./09 16:32 ] |
| Arnaud, je te laisse voir si on peut répondre "facilement" à cette question ou bien s'il faut intégrer cela à un projet CoSAV. Merci |
| Commentaire de Arnaud Forgues [ 01/avr./09 11:04 ] |
| A faire en Chasse, au moins pour la réponse à la question et si c'est simple à faireà boucler en chasse également, sinon retour à dispatcher TX pour priorisation dans un CoSAV |
| Commentaire de Cedric Favero [ 21/juil./09 11:24 ] |
|
Comme vu à l'époque avec Emilien lors du projet
"surveillance vendeurs PRO" , ce mot clé est en dur dans l'appli et est
testé lors du passage du batch panier. Il n'a donc pas été possible de le récuperer au niveau de la surveillance vendeurs. Suite à TX-H , il fonctionne à présent aussi pour les comptes en visibilité 2 mais si on veut le parametrer plus finement, çà passera par une demande spécifique. Dans l'attente , on met en place des rapports BI pour détecter les choses qui nous interessent. |
| Commentaire de Arnaud Forgues [ 21/juil./09 11:35 ] |
| Je renvoie donc la demande chez Dispatcher Pole TX pour précision du besoin puis priorisation via CoSAV |
| Commentaire de Emeric Teil [ 21/juil./09 12:16 ] |
| Inutile donc de conserver ce Jira, la demande, si toujours d'actualité, entrera dans le fichier CoSAV. |
[APP-23783] Intégration du statut d'auto-entrepreneur Création: 22/déc./08 17:26 Mise à jour: 03/avr./09 12:12 Résolue: 27/mars/09 15:48 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Compte utilisateur |
| Affecte la/les version(s): | 36.1.0 |
| Version(s) corrigée(s): | 44.0.0 (TX-F) |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Benoit Tabaka | Attribution: | Dispatcher (Traduction) |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
page_item_bo.jpg
page_user_bo.jpg
propal.jpg
|
||||||||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Site: | Prod | ||||||||
| Projets PM: | *** RESERVE *** | ||||||||
| Description |
|
Il s'agit de procéder à des modifications du F.O. pour
intégrer le statut d'auto-entrepreneur qui entre en vigueur le
01.01.2009 L'auto-entrepreneur aura 1 numéro d'immatriculation (SIRET) L'auto-entrepreneur n'aura pas de raison sociale + aura le même régime que le micro-entrepreneur (non récupération de la TVA). Il s'agit ici de modifier le F.O. pour indiquer aux gens qu'ils peuvent s'inscrire : - à titre professionnel (et non comme une société) - qu'ils doivent cliquer sur le bouton "micro-entreprise" s'ils sont auto-entrepreneur. le champ raison sociale sera obligatoire (ce qui normalement ne doit pas l'être), mais finalement on se passera de cela (et on leur dira d'indiquer dedans qu'ils sont auto-entrepreneur). En PJ, ce que cela pourrait donner. |
| Commentaires |
| Commentaire de Emeric Teil [ 22/déc./08 17:49 ] |
|
Benoît : -> Les micro-entreprises sont-ils censés avoir une raison sociale ? Si ce n'est pas le cas, on peut éventuellement envisager de ne plus proposer ce champs si l'option "ME ou AE" est sélectionnée. |
| Commentaire de Benoit Tabaka [ 22/déc./08 17:57 ] |
|
Bonne Question Emeric. Je viens de rechercher. Une micro-entreprise "ne peut pas être une société, il s'agit obligatoirement du statut juridique de l'entrepreneur individuel". Donc, si une micro-entreprise n'est pas une société, cela veut dire qu'elle n'a pas de raison sociale (terme réservé aux SA, SARL, EURL, etc.) Donc, effectivement, si ME/AE est sélectionné, on peut décider de masquer le champ "Raison sociale". |
| Commentaire de Emeric Teil [ 22/déc./08 18:31 ] |
|
Dernière question : -> Est-on sereins sur le fait qu'on ne pourra pas distinguer AE et ME ? |
| Commentaire de Benoit Tabaka [ 22/déc./08 18:34 ] |
|
Emma nous a indiqué que les commerciaux mentionneraient dans
4d le fait que l'utilisateur est AE, si nécessaire on pourra donc les
retrouver. En outre, certaines règles de gestion vont aussi être adoptées d'un commun accord entre les commerciaux et le BO pour faire attention à ces nouveaux "pro". Enfin, en toute logique économique, les micros-entrepreneurs devraient disparaître pour être AE vu que le régime est meilleur ! |
| Commentaire de Cedric Favero [ 23/déc./08 09:22 ] |
|
" Est-on sereins sur le fait qu'on ne pourra pas distinguer AE et ME ? " Je repondrais par une question moi meme. A-t-on un moyen simplte de les indentifier en base sans gros dev? Savoir si on pourrait les retrouver dans BI ou faire des regles de mots clés particulieres.. Car à terme , une indication dans le compte ou dans 4D s'averera certainement insuffisante... Mais si celà a un impact plus large, on verra dans un second temps.. |
| Commentaire de Emeric Teil [ 23/déc./08 11:27 ] |
| C'est possible, cependant il y aura du Dev supplémentaire, et cela ne pourra intégrer le Projet TVA (actuellement, "Auto-Entrepreneur") est sorti de la RoadMap TX, en accord avec le CoEx. |
| Commentaire de Emeric Teil [ 24/mars/09 16:44 ] |
|
OK donc pour conclure, deux choses : -> Modifier le label Front Office : "Je déclare bénéficier du régime fiscal de « micro entreprise « ou être déclaré « auto-entrepreneur « et ne pas posséder de N° de TVA Intracommunautaire. " -> En BO, sur les pages User et Item, ajouter, à côté du wording "PRO" la mention "EI" si le compte isMicroCompagny |
| Commentaire de Fabien Bourdoulous [ 24/mars/09 18:43 ] |
|
Labels à publier dans IG : /default/Labels/_Mon Compte/_Espace Vendeur/SellerProfileProCompanyInclude/info_precise_micro_company_status - French (French) (274660) Est-ce que la modification du label concerne aussi ES et UK ? Dans ce dernier cas, demander les traductions. |
| Commentaire de Fabien Bourdoulous [ 25/mars/09 11:46 ] |
|
Label à traduire en UK & ES : /default/Labels/_Mon Compte/_Espace Vendeur/SellerProfileProCompanyInclude/info_precise_micro_company_status - French (French) (274660) |
| Commentaire de Rocio Perez-Garcia [ 26/mars/09 13:00 ] |
| Ajouté "auto-empresario" à la traduction espagnole. |
| Commentaire de Rémi Virlouvet [ 26/mars/09 13:03 ] |
|
auto-entrepreneur sur UK fait sur cms 1 |
[EXP-4604] Mailing vers les pros pour inciter à mettre le compte en vacances si absent pour la période de Noël Création: 05/nov./08 12:36 Mise à jour: 17/nov./08 09:47 Résolue: 12/nov./08 09:54 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Gaël Seguillon | Attribution: | Patrice Boulanger |
| Résolution: | Invalid | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Cher partenair1.doc
Cher partenaire.doc
|
| Pays: |
FRA - France
|
| Description |
|
Pour la période des fêtes de fin d'année comme pour les
grandes vacances il faut adresser à toute notre base de pros actifs un
mail les invitant à se mettre en vacances. en pj le mail à en voyer
foramt txt et html n'hésitez pas à me contacter si vous avez besoin de plus d'infos merci Gaël |
| Commentaires |
| Commentaire de Patrice Boulanger [ 12/nov./08 09:54 ] |
|
C'est pas l'exploit qui envoie ce genre de mail, à voir
plutôt avec le BI. Ce genre de mail doit être envoyé via 1000Mercis. Merci. |
| Commentaire de Patrice Boulanger [ 17/nov./08 09:47 ] |
|
Question: Salut Patrice, Je reviens vers toi concernant ma demande http://pricejira.lan/browse/EXP-4604 En fait j'avais vu ça avec le marketing avant et c'est eux qui m'ont assuré la possibilité de cet envoi par l'équipe d'exploit, l'idée était justement de ne pas passer par 1000 mercis car pour un mailing vers 3000 personnes il vont nous facturer au moins 300 euros. Merci Gaël Réponse: Le fait que 1000Mercis fasse payer ce genre de prestation n'est pas étonnant, ils ont des accords avec les opérateurs pour réaliser ce genre d'envoi massif afin de ne pas se faire blacklister. Ce n'est pas notre cas. On ne va pas risquer de faire blacklister nos mailers (au bureau ou, pire, sur la plateforme de prod) pour 3000 mails. Enfin, nous n'avons pas les outils nécessaires pour faire cela. Donc, il faut passer par 1000mercis. Patrice. |
[CAT-1860] Problème frais de port associés aux livres Création: 06/juil./09 11:32 Mise à jour: 04/sept./09 09:41 Résolue: 04/sept./09 09:41 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Non Import |
| Composants: | Frais de port |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Xavier Fabregat | Attribution: | Rocio Perez-Garcia |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
screenshot-1.jpg
|
||||||||
| Liens des demandes: |
|
||||||||
| Pays: |
ESP - Espagne
|
||||||||
| Description |
|
Des nombreux livres sont associés à la taille 7 (donc transaction en mode d'envoi "normal" interdite. Apparemment le souci est lié au poids de l'article car on trouve toute sorte de livres (BD, litterature, Beaux-arts,...) , de toutes les tailles (grand format, moyen,...) et soumis à partir du Front office ou par fichier d'import. Si le livre n'a pas de poids ou si celui-ci est supérieur à 1kg, il passe en T7 automatiquement Exemples: http://bo.priceminister.es/referential_back?action=productview&productid=22087649 http://bo.priceminister.es/referential_back?action=productview&productid=46632233 Merci |
| Commentaires |
| Commentaire de Emeric Teil [ 09/juil./09 16:53 ] |
| Voir Arnaud si questions sur le bon paramétrage à effectuer... |
| Commentaire de Marion Anfreville [ 10/juil./09 15:17 ] |
|
ATTENTION : bien prévenir l'équipe d'exploitation (Eric
Vannier pour les flux partenaires) + le market + l'équipe BI (Agathe) si
changement dans les frais de port. Il peuvent avoir à faire des adaptations pour prendre en compte les modifications apportées. |
| Commentaire de Julien Sananikone [ 04/août/09 11:23 ] |
| essaye de voir ce qui se passe et tiens moi au courant |
| Commentaire de Rocio Perez-Garcia [ 06/août/09 12:06 ] |
|
Dans la MeV FO, le problème est lié au paramètrage des fdp
pour les livres. On prend en compte pour les déterminer : le poids, le
format, la taille et le prix. Mais pour le format tous les valeurs ne sont pas paramètres. Si dans la MeV on choisi un valeur qui n'est pas dans l'arbre, il passera automatiquement dans la T(7). Sur la FR, le format comprend seulement les valeurs Grande, Moyen et Petit (pris en compte en Es dans Taille). Je propose désactiver le n¿ud Format en Espagne pour les Frais de Port et prendre en compte trois paramètres comme sur la France. Qu'en pensez vous ? |
| Commentaire de Rocio Perez-Garcia [ 12/août/09 18:01 ] |
|
Dans le cas du Jira Ce problème peut être résolu comme dit précédemment. Par contre, si on veut autoriser l'envoi en Normal pour les livres de plus d'un kilo, ce serait plus simple de créer une nouvelle taille de frais de port. A voir et discuter entre les équipes pertinents. |
| Commentaire de Gaël Seguillon [ 19/août/09 14:59 ] |
|
Vu avec Rocio on passe à un système différent pour contourner le problème On se base sur le système du site Fr Seul le champ poids détermine le remboursement du port, le format ou type de livre n'est plus pris en compte sur l'attribution d'un remboursement de frais de port. On rajoute dans le formulaire de soumission un champ poids petit = jusqu'à 350 g moyen de 350 à 1000 g grand au dessus de 1000 g (1 kg) On rend le champ format/type de livre facultatif lors de la mise en vente. Quand le poids n'est pas renseigné on met par défaut le poids moyen merci Gaël |
| Commentaire de Aurélien Vergalli [ 19/août/09 15:31 ] |
|
Gael : "On rajoute dans le formulaire de soumission un champ poids" => CAD préciser les 3 plages de poids correspondant aux 3 tailles de la droplist "Tamaño" du formulaire, comme en FR, c'est bien ça ? Gael : "Quand le poids n'est pas renseigné on met par défaut le poids moyen" => concerne les imports avec poids et taille non renseignés ? |
| Commentaire de Rocio Perez-Garcia [ 19/août/09 18:27 ] |
|
L'idée est: - Désactiver le n¿ud "Type d'ouvrage" comme paramètre pour déterminer les frais de port et adapter le formulaire MeV avec les plages de poids comme sur FR. Eric nous confirmera pour le flux partenaires avant de le réaliser. |
| Commentaire de Gaël Seguillon [ 20/août/09 11:57 ] |
|
Pou répondre à Aurélien oui ça concerne les imports pour la partie soumission en front il faut laisser le choix de la catégorie de poids obligatoire ok là dessus ? |
| Commentaire de Aurélien Vergalli [ 21/août/09 09:37 ] |
| Ok pour moi. |
| Commentaire de Eric Vannier [ 01/sept./09 14:56 ] |
|
pour résumer : Pour déterminer les frais de port d'un livre, il faut : le poids => PAS OBLIGATOIRE déterminé dans ce cas par la taille la taille le prix => permet en france de savoir si on passe en recommandé... est-ce que pour l'espagne on a un équivalent ou bien le prix n'est pas utile ? C'est ça ? |
| Commentaire de Rocio Perez-Garcia [ 01/sept./09 15:03 ] |
|
Merci Eric, oui c'est ça. Alors pour le prix, comme on a
déjà discuté, on conserve le paramètrage actuel, c'est à dire: Petit : moins de 12.2 (T.190) Moyen : Entre 12.2 et 45.73 (T.4.60) Grand : Plus de 45.73 (T.7) |
| Commentaire de Rocio Perez-Garcia [ 02/sept./09 09:28 ] |
|
Fait en preview (et testé en Integ). - Désactivé le noeud dans les frais de port qui prenait en compte le Type d'ouvrage pour le calcul. - Modification des valeurs "taille" dans le formulaire Mise en Vente FO, pour préciser les plages de poids selon la taille. Merci à tous ! |
[IMP-3870] profil partenaire : intellishop Création: 29/juin/09 17:12 Mise à jour: 30/oct./09 15:44 Résolue: 13/août/09 11:31 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Skender Berisha | Attribution: | Jérome Marianne |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
intellishop.xls
|
| Pays: |
FRA - France
|
| Login: | intellishop |
| Séparateur: | Point-virgule (;) |
| Type de traitement: |
Mise à jour/création annonces avec mise à jour/création produits (écrasement)
|
| Description |
|
Bonjour Serait-il possible d'enlever le modèle neteven avec ce partenaire, il ne travaille plus avec eux. Merci de lui remettre un profil de FTP standard : gestion flux de commande + import de stock. je lui ai fait un export de son stock, il aura comme ça les id product price. Merci Skender |
| Commentaires |
| Commentaire de Frédéric Nahum [ 30/juin/09 10:29 ] |
| il me faut le fichier car sinon je ne peux pas connaitre l'ordre des colonnes |
| Commentaire de Skender Berisha [ 30/juin/09 10:34 ] |
|
je lui ai fai un export de stock bi, il va se servir de ce fichier ça te convient ? Merci Skender |
| Commentaire de Jérome Marianne [ 16/juil./09 18:13 ] |
|
Avec ce fichier le pro ne pourra faire que la création annonces. Pour créer des produits il faudra qu'il utilise le modèle "accessoire audio vidéo". |
| Commentaire de Jérome Marianne [ 06/août/09 17:52 ] |
|
Le format Neteven à été retiré. Le pro peut-il utiliser un de nos formats pour la mise à jour? |
| Commentaire de Frédéric Nahum [ 12/août/09 16:39 ] |
| ou en est cette demande ??? |
| Commentaire de Jérome Marianne [ 13/août/09 11:31 ] |
|
Le format Neteven à été enlevé. Les formats "Vêtements" et "bouquiniste" qui étaient paramétrés dans le compte ont été passés en écrasement. Le flux de commande était déjà paramétré dans le FTP. Concernant les annonces Accessoires High Tech, il faut donner au pro le format minimaliste et ouvrir un nouveau JIRA pour le paramétrage. |
[BIN-621] [CRM achat] : Création d'un rapport sur paniers abandonnés Création: 31/juil./09 11:31 Mise à jour: 29/janv./10 09:29 Résolue: 30/déc./09 09:54 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | CRM |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Nouvelle fonctionnalité | Priorité: | Majeur |
| Rapporteur: | Julien Meraud | Attribution: | Dalila Belkebir |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Nous utilisons actuellement un rapport disponible dans mon perso sur ur marketing qui nous donne le nombre de paniers abandonnés et le nombre de membres ayant abandonné un panier. Nous venons de nous rendre compte que la jointure naturelle entre la table purchase et user diminue énormément le nombre de paniers abandonnés (seuls sont pris en compte les paniers des abandonnistes loggés j'imagine) Nous lançons actuellement beaucoup d'actions sur abandonnistes non loggés et nous souhaiterions construire un rapport donnant par jour, le nombre de paniers abandonnés, le nombre d'abandonnistes (il suffit de reprendre le rapport existant et de faire une jointure externe) avec un split par loggés/non loggés (en fonction de l'existence d'un nom dans la table purchase) plus un 2e onglet avec un split par catégories (pas de split loggés/non loggés ici) Je suis à votre disposition en cas de demande, Julien |
| Commentaires |
| Commentaire de Dalila Belkebir [ 30/déc./09 09:54 ] |
|
Bonjour, La demande est livrée sur les plateformes France, UK & ESPAGNE. Vous y trouverez donc : - Dans le répertoire existant Purchase - Un nouveau rapport « Monthly purchase activity » Ce rapport a pour objectif le suivi des paniers aux différents stades de son cycle de vie: paniers abndonnés, autorisés, capturés. Ces indicateurs sont suivis par mois de création du panier, et répartis sur trois onglets: nombre total de paniers, paniers standards et paniers négociés. Pour plus d'informations sur le BI, nous vous invitons à consulter les spécifications : T:\BI\00 - Projets\2009-10 Monthly purchase activity Nous attendons donc vos retours pour validation du rapport et des droits users. Cdlt, Dalila. |
| Commentaire de Julien Meraud [ 28/janv./10 14:01 ] |
|
OK pour moi, Merci. |
[BIN-609] [Marketing] : Mailings partenaires Espagne : demande d'extraction de la base Création: 08/juil./09 17:19 Mise à jour: 26/janv./10 17:38 Résolue: 02/déc./09 11:29 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | CRM |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Charles Decaux | Attribution: | Julien Girardet |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Document(1).xls
ko - avec delivery.png
ok - no delivery.png
Requete.jpg
|
| Pays: |
ESP - Espagne
|
| Description |
|
Hello, comme discuté avec Agathe, voici un brief afin de créer un rapport permettant d'extraire les opt-in partenaires de la base Espagne. CONTEXTE ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Aujourd'hui, nous utilisons 1000Mercis pour envoyer des mailings partenaires à nos opt-in partenaires. Cela génère des revenus importants, mais pose plusieurs problèmes : - cela nuit à la réputation des envois "priceletter" sur la France et l'Espagne - cela coûte cher, puisqu'à chaque envoi, 1000Mercis réclame 230¿. Ainsi nous dépensons plus de 2300¿ par mois pour faire des mailings partenaires. C'est trop cher. C'est pourquoi nous souhaitons arrêter de travailler sur ce sujet avec 1000mercis Nous voulons utiliser, uniquement pour les mailings partenaires, une autre solution (à priori e-circle) que Nerea maîtrise bien. OBJECTIF ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Pour travailler avec e-circle, nous devrons uploader avant chaque envoi, la liste des adresses emails dans la base priceminister.es Ainsi, nous souhaiterions la création d'un rapport qui nous fournisse la base de données au format CSV répondant au ciblage suivant : - opt-in partenaires - ayant un compte OU étant un contact contactable. Il est très important que nous ayons bien les contacts contactables car ceux-ci représentent une majorité dans la base de donnée. - email unique : si on peut éviter d'avoir plein de fois le même email ce serait bien. Concernant le contenu de la base de données, nous souhaiterions, dans un monde idéal, disposer de tous les champs suivants. J'ai cependant précisé ceux qui avaient un caractère obligatoire et ceux qui sont facultatifs. Attention, obligatoire ne veut pas dire qu'il ne faut pas mettre le contact/compte si on n'a pas l'info. Obligatoire veut dire qu'on souhaite intégrer l'information si on en dispose. - Nom (obligatoire) - Prénom (obligatoire) - userid (obligatoire pour désabonnement) - email (obligatoire) - login (facultatif) - civilité (facultatif) - année de naissance ou âge (facultatif) - pays (facultatif) - ville (facultatif) - code postal (facultatif) - est actif (acheteur ou vendeur) ? (facultatif) - date d'arrivée dans la base (facultatif) DELAIS --------------------------------------------------------------------------------------------------------------------------------------------------- Nerea est en congés tout le mois de juillet. Si on arrive à mettre en oeuvre ce rapport fin juillet/début août ce serait top AVANCEMENT --------------------------------------------------------------------------------------------------------------------------------------------------- J'ai tenté de faire un rapport, mais j'ai peur qu'il ne contienne pas les contacts contactables. J'ai le sentiment qu'il ne contient que les mails des comptes. Voici l'adresse de ce rapport Mes Dossiers > Favoris > Charles > Opt in partenaires Spain Merci !!!!!!! |
| Commentaires |
| Commentaire de Charles Decaux [ 21/juil./09 12:01 ] |
|
Hello, j'ai crée un rapport. Il se trouve dans Mes Dossiers >> Favoris >> Charles >> Extraction de la base opt-in partenaires Dans ce rapport j'ai demandé les champs suivants : - user first name - user last name - user account id - user email address - user login - user title label - user birth date - user address country name - user address city - user address zip - purchase count (afin de savoir s'il est acheteur ou non) - seller activation date (afin de savoir s'il est vendeur ou non) J'ai ajouté un filtre sur le subscription pour n'avoir que ceux qui sont abonnés aux news partenaires. J'obtiens des résultats. J'ai plusieurs problèmes. 1. Il ne me sort pas les contacts contactables qui n'ont pas de compte. Je n'arrive pas à comprendre pourquoi. 2. Il ne me sort que les comptes ayant effectué au moins un achat 3. Il ne me sort que les comptes où le vendeur est actif Du coup, la liste est fortement restreinte et le rapport ne correspond pas à mon besoin. J'ai mis les résultats en pièce jointe/ Comment faire pour avoir des résultats corrects ? Merci de votre aide |
| Commentaire de Julien Girardet [ 27/juil./09 15:59 ] |
|
Salut Charles, A propos de tes questions : En utilisant l'indicateur "Purchase count" tu auras seulement les comptes acheteurs, et donc tu n'auras pas les contacts Si le but de "purchase count" est de savoir si le compte est acheteur ou pas, je te propose d'utiliser la dimension "First purchase authorization date". Ainsi en fonction de sa valeur (renseigné ou null) tu sais si le compte est acheteur ou pas. Par contre, tu ne peux pas avoir l'info si le user est vendeur en utilisant "seller activation date", ca ne marche pas. Tu es obligé de supprimer cette dimension de ta requete sinon tu filtres uniquement les vendeurs. Enfin, il faut ajouter une condition pour obtenir uniquement les comptes actuellement abonnés aux mails partenaires (sinon tu as aussi les désabonnés) Pour ca, tu utilises le filtre "Active subscription" dans la classe "Mail subscription" Concernant l'email unique, tu ne peux pas avoir un email unique si tu veux dans ton rapport le userid et le nom/prénom. Pour un email peut correspondre plusieurs userid et nom/prénom... Pour info, j'ai fait quelques comptages sur ceux qui sont abonnés aux mails partenaires et qui ont plusieurs comptes pour un meme mail : - 2142 mails correspondant à des multi comptes, soit 4547 comptes En résumé je te propose la requete suivante : - user first name - user last name - user account id - user email address - user login - user title label - user birth date - user address country name - user address city - user address zip - First purchase authorization date Avec comme filtres : - Select subscription type - Active subscription A la date d'aujourd'hui j'obtiens 153307 comptes correspondant aux critères. A ta dispo, si tu as des questions. Julien. |
| Commentaire de Charles Decaux [ 28/juil./09 12:19 ] |
|
Hello Julien, merci beaucoup pour ton aide, ça va vraiment nous faire faire de belles économies ! Concernant le comptage, 1000 mercis envoie les emails opt-in partenaires à 136 698 emails Alors que toi tu indiques 153 307 comptes avec 4547 comptes qui ont la même adresse. L'écart est donc assez important, est-ce qu'on sait pourquoi ? Merci |
| Commentaire de Julien Girardet [ 28/juil./09 14:37 ] |
|
Salut Charles, Quelques pistes pour expliquer l'écart : - les comptes ayant la meme adresse mail. (mon comptage est par compte alors que 1M est par email) - les emails invalides chez 1M - les boucles de rétroaction - les pros (est ce que 1M envoie aux Pro ?, ils sont compris dans mon comptage) |
| Commentaire de Agathe Remy [ 17/août/09 11:26 ] |
|
Bonjour Charles, Est-ce que tu valides cette demande ? Merci. Agathe |
| Commentaire de Charles Decaux [ 17/août/09 11:28 ] |
|
oui c'est parfait. Merci bcp |
| Commentaire de Agathe Remy [ 17/août/09 11:35 ] |
| Merci! |
| Commentaire de Julien Girardet [ 26/août/09 11:34 ] |
|
Bonjour Charles, Suite a la refonte de la gestion des adresses dans BI (livré hier), ton rapport "Extraction de la base opt-in partenaires" ne peut plus fonctionner. Tu utilises dans ce rapport plusieurs dimensions qui n'existent plus dans l'univers USER ACCOUNT : - user address country name - user address city - user address zip Ces dimensions correspondaient à l'adresse d'un user par défaut. Aujourd'hui les dimensions adresses sont dans la classe "User address". Un user peut avoir plusieurs adresses, pour les différencier il faut utiliser le "User address type code/label" : 10 DELIVERY Livraison 20 PAYMENT Paiement 30 GAME Jeu 40 CUSTOMER_SERVICE SAV 50 SELLER_CONTACT Contact vendeur 60 BUYER_CONTACT Contact acheteur 70 PICKUP Enlevement 80 RETURN Expedition En conclusion il faut prendre les dimensions dans la classe User address : - user address country name - user address city - user address zip Et choisir un type d'adresse en filtre. Je te conseille l'adresse de livraison, c'est surement la plus renseignée. Donc par exemple "User adress type code = 10" dans la partie filtre de ta requete. N'hesites pas a venir nous voir si tu as des questions. Julien. |
| Commentaire de Charles Decaux [ 03/sept./09 14:22 ] |
|
Salut Julien, en fait j'ai un souci. J'ai mis dans les filtres user address type label= delivery Le problème c'est qu'il me donne uniquement les account de users qui ont renseigné cette donnée. Or, je voudrais également pouvoir obtenir les informations des comptes n'ayant pas renseigné cette donné. Sais-tu comment je dois procéder ? Merci |
| Commentaire de Julien Girardet [ 03/sept./09 14:38 ] |
|
Salut Charles, En effet, il faut ajouter une condition si tu veux les comptes n'ayant pas d'adresse de livraison. Donc la condition doit être : user address type label= delivery OU user address type label est null ci joint un screenshot de la requete. N'hesites pas a passer me voir si tu as besoin d'aide. Julien |
| Commentaire de Julien Girardet [ 03/sept./09 14:38 ] |
| Requete BO |
| Commentaire de Charles Decaux [ 10/sept./09 15:06 ] |
|
Salut Julien En faisant un export de ma base, je me suis rendu compte qu'il manquait des comptes récents. Par exemple, le compte kakily77 est bien optin partenaire dans le back office, mais n'apparaît pas dans les résultats de la requête. J'ai testé sans mettre les filtres liés à l'adresse, et à ce moment là, cela m'a bien affiché le compte de kakily77 Peux-tu regarder ? Merci ! |
| Commentaire de Agathe Remy [ 10/sept./09 15:06 ] |
|
Bonjour Charles, Est-ce que je peux fermer ce JIRA? Merci. Agathe |
| Commentaire de Charles Decaux [ 10/sept./09 15:06 ] |
|
quand j'enlève les conditions de delivery, j'ai bien le compte kakily77 |
| Commentaire de Charles Decaux [ 10/sept./09 15:07 ] |
|
quand je remets les filtres delivery, je n'ai plus kakily77 |
| Commentaire de Dalila Belkebir [ 21/sept./09 17:02 ] |
|
Bonjour Charles, Comme vu avec Agathe, est-ce que je peux fermer ce JIRA? Merci. Dalila. |
| Commentaire de Charles Decaux [ 24/sept./09 16:05 ] |
|
hélas, non, on aimerait bien avoir la delivery address c'est possible ? |
| Commentaire de Julien Girardet [ 27/nov./09 15:16 ] |
|
Comme vu avec Charles, l'ajout de l'adresse de livraison est toujours d'actualité Le rapport devra etre placé dans le repertoire de Benjamin (UR SALES). |
| Commentaire de Julien Girardet [ 02/déc./09 11:29 ] |
|
Salut Charles, Le rapport "Extraction de la base opt-in partenaires " avec l'adresse de livraison est dispo dans le repertoire de Benjamin (ur sales). Julien. |
[IMP-5813] PRO se plaint Commandes non transmises par FTP -Booksxpress Création: 16/avr./10 10:30 Mise à jour: 16/avr./10 13:42 Résolue: 16/avr./10 13:42 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Support entrant |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Daniel Pintamalli | Attribution: | Daniel Pintamalli |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Login: | Booksxpress |
| Séparateur: | N/A |
| Type de traitement: |
N/A
|
| Description |
|
De : efim [mailto:efim@dvdlegacy.com] Envoyé : lundi 29 mars 2010 20:58 À : daniel.pintamalli@priceminister.com; 'Gael Seguillon'; caroline.vallerey@priceminister.com Cc : 'michael abitbol'; 'efim' Objet : FW: Your account Priceminister Importance : Haute Bonjour Daniel, Ce n'est pas la première fois nous n'avons pas reçu des commandes de priceminister.fr (compte: Booksxpress) Pourriez-vous vérifier et corriger le problème. Je prends toujours tous les fichiers placés dans le dossier \purchase Je garde le fichier que j'ai pris dans mon 'history'; aussi que j'ai un fichier journal avec toutes les informations. S'il vous plaît, donnez-moi les noms de fichiers où vous avez mis ces commandes: 84392718 25/03/2010-18:37 Nouvelle 2 articles et 84450111 27/03/2010-01:45 Nouvelle 1 article Merci, Efim. |
| Commentaires |
| Commentaire de Daniel Pintamalli [ 16/avr./10 13:42 ] |
|
Mail envoyé au pro: De : Daniel Pintamalli [mailto:daniel.pintamalli@priceminister.com] Envoyé : vendredi 16 avril 2010 13:42 À : 'efim' Cc : 'michael abitbol'; 'Gael Seguillon'; 'param-imp@priceminister.com'; 'Jérôme Viviès'; 'Jeremy Pallot'; 'carlos.cantoni@priceminister.com' Objet : Priceminister - booksxpres Importance : Haute Bonjour Efim, On a constaté que certaines commandes que vous n'avez pas reçues par le biais du compte FTP, sont dues au fait que votre script récupère parfois le même fichier « purchase » 2 fois à la même heure, le 2ème écrasant le primer chez vous. Cela se produit parce que les fichiers s'appellent pareil quand il s'agit de la même heure. Afin de contourner ce cas de figure il est nécessaire que votre script passe chercher vos commandes 1 fois par heure, entre la minute 45-50. Ainsi, vous n'aurez plus de commandes manquantes. Cordialement, |
[APP-29119] Suppression du tracking Automatisation Création: 12/avr./10 16:05 Mise à jour: 22/juin/10 10:01 Résolue: 03/mai/10 17:56 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Tracking |
| Affecte la/les version(s): | 66.0.1 |
| Version(s) corrigée(s): | 71.0.0 (CTN-R) |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Julien Meraud | Attribution: | Alexandre Garnier |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
CTN-R_APP-29119_FR_update_ust_group.sql
RépartitionTrackingAutomatisation.xlsx
|
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM: | *** CHASSE *** |
| Classif FONC: | divers |
| Description |
|
*** Pour Dispatcher CTN *** Bonjour, Le groupe de tracking Automatisation est devenu beaucoup trop complexe car il mélange de l'Achat, de la Vente et même un peu de fonctionnalités. Nous avons donc créé de nouveaux groupes de tracking (CRM-Achat, CRM-Vente, CRM-Fonctionnalités, Test-Vente et Test-Achat) dans Xiti et le BO. Il faudrait donc affecter les tracking du groupe Automatisation dans ces nouveaux groupes en respectant la classification présente dans le fichier xls en PJ. Il y a aussi des codes présents dans d'autres groupes de tracking et qu'il faudrait affecter dans le groupe CRM-Fonctionnalités : Groupe Actuel Nom du tracking Code Default CRM_Memos 2242340 Parrainage Relance_ParrainsSansFilleuls 2013240 Parrainage reveil-FD 1824440 Parrainage relance-auto-FD 1824441 A partir de la création de ce JIRA, nous ne créerons plus de code de tracking dans le groupe automatisation mais dans les nouveaux groupes. A votre disposition en cas de questions, Julien |
| Commentaires |
| Commentaire de Fabrice Feugas [ 13/avr./10 15:17 ] |
| A faire sous forme de script (?). |
| Commentaire de Fabrice Feugas [ 14/avr./10 14:09 ] |
| Attention de bien se synchroniser avec le market au moment où vous traiterez ce JIRA. Merci d'aller voir Julien et Odile à ce moment et de valider avec eux toutes les modifications à venir. |
| Commentaire de Alexandre Garnier [ 03/mai/10 15:02 ] |
|
Normal que dans le fichier Excel, il y ai des migrations de groupe vers : * Parrainage (tracking 1490042[M15-parrain-avec-FAFD]) * PL-Mode (tracking 2279740[PL_IDKDO_0112]) * Marketing Communautaire (trackings 2292440[QuestionBlogOui] et 2292441[QuestionBlogNon]) ?? |
| Commentaire de Audrey Angleys [ 03/mai/10 15:06 ] |
|
Salut Alexandre, C'est normal en ce qui concerne le PL Mode (c'était une vieille erreur de groupe de tracking) et pour Marketing Communautaire. Je laisse Carole répondre pour le parrainage. Merci d'avance, A ta dispo pour toute question. Audrey |
| Commentaire de Carole Visser [ 03/mai/10 15:08 ] |
|
C'est normal aussi pour le parrainage. Merci Carole |
| Commentaire de Alexandre Garnier [ 03/mai/10 17:08 ] |
|
OK, c'était juste pour être sûr. Le seul truc merdique c'est que je suis obligé de créer exactement les mêmes groupes en DEV et INTEG pour tester... |
| Commentaire de Alexandre Garnier [ 03/mai/10 17:44 ] |
|
Au passage, je me posais quelques questions sur l'interface BO des codes et groupes de trackings : * le lien de connexion XiTi est-il encore utile (de toute façon il ne fonctionne plus, on peut éventuellement le mettre à jour) * les liens d'affichage des stats XiTi par groupe et par code sont-ils encore utiles (de toute façon ils ne fonctionnent plus, et ne peuvent plus fonctionner : * les liens d'affichage des rapports par groupe et par code sont-ils encore utiles (amènent vers http://intra.priceminister.com/stats/reports/confid/Tracking_Reports/CRM-Achat/ alors que maintenant vous utilisez les rapports BI, non ?) |
| Commentaire de Alexandre Garnier [ 03/mai/10 17:49 ] |
| A priori OK : http://bo.ref-fr.pm.dev/tracking_back?action=ustgroupsearch&fuzzy=false&numberrows=100&startdate=03%2F04%2F2010 aux trackings inexistants en DEV près. |
| Commentaire de Alexandre Garnier [ 03/mai/10 17:55 ] |
|
Les 127 premiers existent en DEV (jusqu'à "Post-Achat"), le reste non. Pour cela, c'est bien OK en DEV. |
| Commentaire de Alexandre Garnier [ 03/mai/10 17:56 ] |
| [CAJ2010Q2CTN] |
| Commentaire de Carole Visser [ 04/juin/10 11:57 ] |
| OK pour moi concernant le groupe CRM fonctionnalité |
| Commentaire de Alexandre Garnier [ 04/juin/10 15:49 ] |
|
Donc je rappelle : tous les trackings créés après l'été
dernier n'existent pas en DEV, donc normal de ne pas les avoir ici. Je vous indique quand ce sera OK en INTEG où ils devraient a priori tous exister. |
| Commentaire de Audrey Angleys [ 04/juin/10 15:53 ] |
| OK merci! |
| Commentaire de Alexandre Garnier [ 04/juin/10 17:19 ] |
| Vérifiable en INTEG : http://bo.pm.lan/tracking_back?action=ustgroupsearch&fuzzy=false&numberrows=100&startdate=03/04/2010 |
[APP-28836] Quamedia : Vérification/Mise à jour du tag + ajouts nouveaux codes de tracking Création: 19/mars/10 18:30 Mise à jour: 12/avr./10 11:44 Résolue: 09/avr./10 11:55 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Infoglue, Tracking |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 66.0.1 |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Claire Genty | Attribution: | Carole Boucheny |
| Résolution: | Corrigé | ||
| Σ Estimation restante: | 0 minutes | Estimation restante: | 0 minutes |
| Σ Temps consacré: | 45 minutes | Temps consacré: | 45 minutes |
| Σ Estimation originale: | Non spécifié | Estimation originale: | Non spécifié |
| Pièces jointes: |
Quamedia tracking codes.xlsx
Quamediagroup_Tag Eulerian.txt
tag quamedia.pptx
|
||||||||||
| Sous-tâches: |
|
||||||||||
| Pays: |
FRA - France
|
||||||||||
| Projets PM: | *** A PLANIFIER *** | ||||||||||
| Classif FONC: | comarket |
| Description |
|
Bonsoir, Nous allons lancer très prochainement une campagne Quamedia. Une campagne de ce type a déjà été lancée. Le tag Quamedia est-il encore présent? Si oui, il se peut qu'il faille le mettre à jour. Ajout d'un paramètre donnant l'information sur le contenu du panier acheté. (pour optimiser le trafic). Voici le nouveau tag à mettre en place/mettre à jour : <!-- Eulerian Analytics - priceminister-fr / scartamount --> <script type="text/javascript" src="http://qua.eulerian.net/ea.js"></script> <script type="text/javascript"> /*<![CDATA[*/ EA_collector([ 'ref', 'REFERENCE_UNIQUE_DE_LA_COMMANDE' ,'amount', 'MONTANT_DE_LA_COMMANDE' ,'type', 'TYPE_DE_COMMANDE' ,'payment', 'TYPE_DE_PAIEMENT' ,'prdref', 'REFERENCE_PRODUIT_VENDU 1' ,'prdamount', 'MONTANT_UNITAIRE_PRODUIT_VENDU 1' ,'prdquantity', 'QUANTITE_PRODUIT_VENDU 1' ,'prdname', 'NOM_DU_PRODUIT_VENDU 1' /* optionnel */ ,'prdref', 'REFERENCE_PRODUIT_VENDU 2' ,'prdamount', 'MONTANT_UNITAIRE_PRODUIT_VENDU 2' ,'prdquantity', 'QUANTITE_PRODUIT_VENDU 2' ,'prdname', 'NOM_DU_PRODUIT_VENDU 2' /* optionnel */ ,'prdref', 'REFERENCE_PRODUIT_VENDU 3' ,'prdamount', 'MONTANT_UNITAIRE_PRODUIT_VENDU 3' ,'prdquantity', 'QUANTITE_PRODUIT_VENDU 3' ,'prdname', 'NOM_DU_PRODUIT_VENDU 3' /* optionnel */ ]); /*]]>*/ </script> <!-- /Eulerian Analytics - priceminister-fr / scartamount --> De plus, de nouveaux codes de tracking ont été créés au sein du groupe Quamedia. Vous trouverez en pj tous les codes de tracking de ce groupe. Il faudrait que le nouveau tag se déclenche pour tous les codes de tracking Ebay (cf. liste ci-après) : 2294340 2294341 2294342 2294343 2294344 2294345 2294346 2294347 2294348 2294349 2294350 2294351 Merci Claire |
| Commentaires |
| Commentaire de Claire Genty [ 19/mars/10 18:31 ] |
| Codes de tracking Quamedia |
| Commentaire de Claire Genty [ 19/mars/10 18:31 ] |
| Tag Quamedia Eulerian Fourni |
| Commentaire de Marion Anfreville [ 25/mars/10 13:50 ] |
| J'ai planifié le paramétrage pour cette demande la semaine prochaine (S13) avec mise en prod S14 (à priori, le 08/04). |
| Commentaire de Carole Boucheny [ 30/mars/10 11:35 ] |
|
Bonjour, Je l'ai mis en place sur cms ref : http://www.ref-fr.pm.dev/info/home?t=2294340 Il semble que les variables suivantes ne soient pas récupérées : ,'type', 'TYPE_DE_COMMANDE' ,'payment', 'TYPE_DE_PAIEMENT' ,'prdname', 'NOM_DU_PRODUIT_VENDU 1' /* optionnel */ Exemple de ce que j'obtiens : <!-- Eulerian Analytics - / scartamount --> <script type="text/javascript" src="https://www.ref-fr.pm.dev/res/co/0/www/www/59901/ea.js"></script> <script type="text/javascript"> /*<![CDATA[*/ EA_collector([ 'email', 'pauldavidwilliamms@btinternet.com.toto' ,'ref', '70608843' ,'amount', '34.43' ,'prdref', '104715338' ,'prdamount', '11.00' ,'prdquantity', '1' ,'prdref', '104715337' ,'prdamount', '2.56' ,'prdquantity', '1' ,'prdref', '104715339' ,'prdamount', '6.00' ,'prdquantity', '1' ,'prdref', '104715336' ,'prdamount', '0.90' ,'prdquantity', '1' ]); /*]]>*/ </script> <!-- /Eulerian Analytics - / scartamount --> |
| Commentaire de Carole Boucheny [ 31/mars/10 11:10 ] |
|
Claire, Peux-tu recetter stp ? Pour tester c'est le même principe que pour le jira : Merci Carole |
| Commentaire de Claire Genty [ 31/mars/10 11:40 ] |
|
Carole, Je viens de tester et voici ce que j'obtiens. <!--@@@ Panier : Event - Buy --> <!-- Eulerian Analytics - / scartamount --> <script type="text/javascript" src="https://www.ref-fr.pm.dev/res/co/0/www/www/59901/ea.js"></script> <script type="text/javascript"> /*<![CDATA[*/ EA_collector([ 'email', 'fabrice.feugas+acheteurfab@gmail.com' ,'ref', '70608844' ,'amount', '3.80' ,'prdref', '104715340' ,'prdamount', '0.90' ,'prdquantity', '1' ]); /*]]>*/ </script> <!-- /Eulerian Analytics - / scartamount --> <!--@@@ End of transaction tag : Event - Buy --> Effectivement, les variables suivantes ne sont pas récupérées : ,'type', 'TYPE_DE_COMMANDE' ,'payment', 'TYPE_DE_PAIEMENT' ,'prdname', 'NOM_DU_PRODUIT_VENDU 1' /* optionnel */ Comment cela se fait-il? Merci Claire |
| Commentaire de Alexandre Garnier [ 01/avr./10 12:48 ] |
|
Là je crois qu'il y a un gros mélange : * ce qui a été intégré est nullement dynamique * ce qui semble ressortir lors des recettes, ce sont les tags EULERIAN des "Emails abandonnistes" (/promotions/Promotions/FR/Affiliation/Emails abandonnistes/) ! Ce qui soulève un problème : comment vont fonctionner 2 tags EULERIAN identiques en parallèle ? |
| Commentaire de Carole Boucheny [ 01/avr./10 14:08 ] |
|
Alexandre, Est-ce qu'utiliser les flux BI comme tu proposais dans la sous-tâche règlerais le problème ? Par contre, je ne sais pas du tout comment ça fonctionne... Claire, Est-ce que de ton côté ça pourrait-être une solution envisageable ? Merci Carole |
| Commentaire de Alexandre Garnier [ 01/avr./10 14:31 ] |
| Attention, je partais juste dans un délire... |
| Commentaire de Carole Boucheny [ 06/avr./10 14:13 ] |
|
Claire Est-ce que ce tag doit se déclencher uniquement pour un premier achat ? Si oui, peux-tu tester ? Merci |
| Commentaire de Claire Genty [ 06/avr./10 19:47 ] |
|
Carole, Peux-tu me communiquer sur quels événement étaient paramétrés les codes de tracking du tag précédent? Si ces derniers sont paramétrés sur le premier achat, ce tag également. (il me semble que c'était le cas) Merci par avance Claire PS : je teste demain dans la journée |
| Commentaire de Carole Boucheny [ 07/avr./10 08:50 ] |
|
Bonjour Claire, L'ancien tag se déclenchait que sur le premier achat. Par contre, comme l'a noté Alexandre dans le jira en sous-tâche les informations "Type de commande", "type de paiement" et "nom du produit" ne peuvent pas être récupérées. C'est donc pour cela qu'elle ne remontent pas. |
| Commentaire de Claire Genty [ 07/avr./10 17:02 ] |
|
Bonjour Carole, Je viens de tester, ça m'a l'air ok. Si l'ancien tag se déclenchait sur le 1er achat, il en est de même pour celui-ci. Merci Claire voici ce que j'obtiens: <!--@@@ Panier : Event - Buy --> <!-- Eulerian Analytics - / scartamount --> <script type="text/javascript" src="https://www.ref-fr.pm.dev/res/co/0/www/www/59901/ea.js"></script> <script type="text/javascript"> /*<![CDATA[*/ EA_collector([ 'email', 'fabrice.feugas+acheteurfab@gmail.com' ,'ref', '70656044' ,'amount', '3.80' ,'prdref', '104760535' ,'prdamount', '0.90' ,'prdquantity', '1' ]); /*]]>*/ </script> <!-- /Eulerian Analytics - / scartamount --> <!--@@@ End of transaction tag : Event - Buy --> |
| Commentaire de Carole Boucheny [ 07/avr./10 17:07 ] |
|
Claire, Il existe un autre tag Eulerian actuellement, c'est celui-ci que tu as eu. Le tag que j'ai mis en place commence par : <!-- Eulerian Analytics - priceminister-fr / scartamount --> et ne récupère pas l'email. Peux-tu retester avec spot_back : http://bo.ref-fr.pm.dev/spot_back Il faut cocher "traking" et mettre le niveau à "High". Pour l'url, il faut mettre /info/home?t=2294340 Merci Carole |
| Commentaire de Claire Genty [ 07/avr./10 17:36 ] |
| Tag Quamedia sous spot |
| Commentaire de Claire Genty [ 07/avr./10 17:36 ] |
|
Carole, Merci pour cette précision. J'ai retesté via spot avec le code 2294347. Voici donc ce que j'obtiens en pj (je vais y arriver... :-)) Si je comprend bien, nous ne remontons que le nombre de produits achetés? Merci Claire En pj ce que je vois. Je ne trouve pas de tag commençant par <!-- Eulerian Analytics - priceminister-fr / scartamount -->. Je trouve juste : <!-- Eulerian Analytics - / scartamount --> |
| Commentaire de Claire Genty [ 08/avr./10 09:51 ] |
|
Carole, Comme vu avec toi, nous récupérons le bon tag. L'acheteur que j'avais pris avait déjà acheté sur le site. Je ne pouvais donc pas voir le tag 1er achat :-) Merci Claire |
| Commentaire de Carole Boucheny [ 08/avr./10 10:04 ] |
| (Promo) Soumis à publication sur cms ref |
| Commentaire de Carole Boucheny [ 09/avr./10 11:55 ] |
| Publié sur cms ref |
[BIN-644] [Marketing] : Validation et disposition dans un dossier public du rapport "Affiliation sur commission nette hors FP par groupe de tracking du panier et filtre sur 30jrs !!!" Création: 07/janv./10 15:52 Mise à jour: 25/janv./10 16:34 Résolue: 25/janv./10 10:50 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Partners |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Jonathan Gorges | Attribution: | Cyril Tanneau |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Avec Dalila, nous avons corrigé un rapport appelé "Affiliation sur commission nette hors FP par groupe de tracking du panier et filtre sur 30jrs !!!", disponible aujour'hui sur Mes Dossiers -> Favoris -> Jonathan. Nous voulons valider et disposer 2 rapports de ce type dans le dossier public Affiliation. La correction qui a été effectuée et qui est cruciale est le Filtre "Last Tracking 30 jours" qui n'était pas présent sur ce rapport. Ainsi, les paniers que nous remontons via ce rapport doivent absolument être Last Tracking 30 jours. Voici les rapports devant être créés: - "Affiliation sur commission nette hors FP par groupe de tracking et par datte": il s'agit exactement de celui disponible dans le dossier Jonathan, avec le filtre Last Tracking 30 jours, et permettant de choisir une date de sélection de ce type [aaaa/mm/jj] - "Affiliation sur commission nette hors FP par groupe de tracking mois coulant": il s'agit du même rapport, avec le filtre Last Tracking 30 jours, mais avec un filtre "mois coulant" à la place de la sélection des dates. -> Nous voulons planifier l'export de ce reporting tous les Lundi à midi pour les groupes de tracking suivant : Affiliationx, Cibleclicx, Zanoxx. -> From : Validation des Ventes [[Groupe de Tracking]] -> Destinataire : affiliation2@priceminister.com PS : afin d'éviter toute confusion, les 3 groupes de Tracking possèdent un "x" à la fin. Une fois de plus, le plus important est de s'assurer que les paniers sont bien Last Tracking 30 jours. Je reste à votre disposition pour toute information complémentaire. Merci d'avance pour votre retour. JG |
| Commentaires |
| Commentaire de Cyril Tanneau [ 08/janv./10 16:23 ] |
|
Jonathan, comme vu ensemble, voici les modifications à apporter sur les rapports BO contenus dans le dossier Public/Pays/Affiliation: Affiliation sur commission nette hors FP par groupe de tracking du panier --> Ajout du tracking 30 jours et déclinaison du rapport sous 2 formes: --> PriceMinister - Affiliation sur commission nette hors FP par groupe de tracking du panier (avec sélection de dates d'autorisation) --> Partner- Affiliation sur commission nette hors FP par groupe de tracking du panier (30 derniers jours autorisation, rapport à planifier) Affiliation sur volume d'affaires par groupe de tracking du panier --> Rapport non utilisé, à archiver Partner - Affiliation purchase checking --> Rapport non utilisé, à archiver PriceMinister - Affiliation purchase checking --> Ajout du tracking 30 jours On ne touche pas aux rapports de type "Seller..." du dossier Affiliation. Peux-tu valider ces modifications et je commence les développements. Merci, Cyril |
| Commentaire de Jonathan Gorges [ 08/janv./10 16:52 ] |
|
Hello, Tout cela est parfait! Merci bcp. JG |
| Commentaire de Jonathan Gorges [ 18/janv./10 12:35 ] |
|
Hello Cyril, Comment vas-tu? Je reviens vers toi concernant les rapports Affiliation sur commission nette hors FP par groupe de tracking du panier. As-tu déjà rajouté le filtre Last Tracking 30 jours ? J'ai essayé d'utiliser ce rapport ce matin mais il me semble que le filtre n'a pas encore été posé. Merci d'avance pour ton retour. JG |
| Commentaire de Dalila Belkebir [ 18/janv./10 14:33 ] |
|
Bonjour Jonathan, Je dois avlider les rapports. Je le fais demain matin et te les livre en prod dans la foulée si tout est ok. Cdlt, Dalila. |
| Commentaire de Jonathan Gorges [ 18/janv./10 14:38 ] |
|
"avlider" ? Vous utilisez de drôles de termes chez BI :-) Blague à part, pas de problème. Merci encore. JG |
| Commentaire de Cyril Tanneau [ 21/janv./10 18:01 ] |
|
Bonjour, Conformment à la demande, les rapports suivants sont passés en prod: --> PriceMinister - Affiliation sur commission nette hors FP par groupe de tracking du panier (avec sélection de dates d'autorisation) --> Partner- Affiliation sur commission nette hors FP par groupe de tracking du panier (30 derniers jours autorisation, rapport à planifier) --> PriceMinister - Affiliation purchase checking Ces trois rapports sont désormais filtrés en "Last tracking 30 jours". Recapitulatif: Vous trouverez donc dans le répertoire affiliation les rapports suivants: France --> PriceMinister - Affiliation sur commission nette hors FP par groupe de tracking du panier --> Partner- Affiliation sur commission nette hors FP par groupe de tracking du panier --> PriceMinister - Affiliation purchase checking Espagne --> PriceMinister - Affiliation purchase checking UK --> PriceMinister - Affiliation purchase checking Jonathan, Benjamin, pouvez-vous valider la demande si cela vous convient? Nous restons à votre disposition pour toute question. merci, Cyril |
| Commentaire de Jonathan Gorges [ 22/janv./10 09:12 ] |
|
Hello, Tout cela me convient parfaitement. Merci pour tout et bonne journée. JG |
| Commentaire de Benjamin Guerville [ 25/janv./10 16:34 ] |
|
ok pour moi merci |
implémentation stats auto
(APP-6505)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Annonces |
| Affecte la/les version(s): | 8.0.9 |
| Version(s) corrigée(s): | 8.1.1 |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | Marc Cacheiro | Attribution: | Edouard Laurent |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Site: | Prod | ||||||||
| Description |
|
(dépendance tâche dev "implémentation stats auto", JIRA n°6505) - à partir des fichiers CSV générés par l'équipe dev via les logs 4J sur chacun des 11 sevreurs applicatifs, création d'une table unique à destination de l'équipe décisionnelle, comprenant pour chaque log enregistré sur les serveurs les colonnes suivantes : . type de page (détail annonce ou liste annonce) . type de vendeur (part ou pro) . id_vendeur . marque . modèle . version . id_annonce . date de consultation - mise à disposition de cette table sur un répertoire partagé à destination de l'équipe décisionnelle |
| Commentaires |
| Commentaire de Sébastien Tournay [ 28/nov./05 18:00 ] |
| PAs certain que cela soit du ressort de l'exploit. Une tache pour le décisio ? Je te laisse voir. |
| Commentaire de Christophe Garcia [ 14/déc./05 10:56 ] |
| Où en est-on SVP ? |
| Commentaire de Christophe Garcia [ 15/déc./05 10:35 ] |
|
Judd, Merci de fournir à Edouard les infos nécessaires à la recup et archivage des fichiers. |
| Commentaire de Judd OSullivan [ 15/déc./05 11:23 ] |
|
Sur chaque machine il y a ce fichiers : /appli/priceminister/jboss/server/priceminister/log/reporting/stats_auto.csv Chaque matin au démarrage il y aura 2 fichiers : stats_auto.csv : les stats depuis minuit stats_auto.csv.2005-12-14 : les stats avant minuit Ensuite il me semble que les deux sont ecrasés parce qu'on supprime le rép ..../priceminister/log. Si on veut integrer leur récuperation dans le processus de démarrage on peut changer log4j pour que tout soit dans un seul fichier. Au moins il faut qu'on copie ces 2 fichiers ailleurs au démarrage. |
| Commentaire de Edouard Laurent [ 15/déc./05 16:09 ] |
|
les stats auto sont dispos sur titan dans /data/priceminister/pmshare/exploit/log4j/work/stats_auto.csv pour l'instant le mecanisme n'est pas automatise |
| Commentaire de Agathe Remy [ 15/déc./05 18:15 ] |
|
En fait, il faudrait chargé les données du fichier .csv dans
une table du Datawarehouse sur Titan (mais qui ne soit pas détruite
pendant la synchro) pour que je puisse faire mes requêtes. Merci:-) |
| Commentaire de Edouard Laurent [ 16/déc./05 12:27 ] |
|
J'ai fait une demande auprès de Didier Blanc, nous avons
déjà ce type de schéma (non supprime) sur titan pour l'archivage en attente de sa réponse. |
| Commentaire de Edouard Laurent [ 16/déc./05 17:31 ] |
|
en regardant un peu le fichier je tombe sur pas mal de lignes comme celle la, particulierement sur venus stats_auto.csv:liste_annonces;part;2618751;null;null;null;null;2005-12-16 15:58:46.277 Bug ? ca parait etrange, ca resemble a une ligne de log qui sert a rien |
| Commentaire de Edouard Laurent [ 04/janv./06 17:03 ] |
|
Collecte des stats auto : ================ en tant que pmas@titan dans le repertoire : /data/priceminister/pmshare/exploit/stats_auto executer le script: ./stats_auto.sh collect une fois la collecte des logs effectue. les fichiers log archives et traites par le mecanisme de collecte sont stockes dans /data/priceminister/pmshare/exploit/stats_auto/archive/ Les enregistrements selectionnes valide par le pre-traitement sont stockes dans le fichier : /data/priceminister/pmshare/exploit/stats_auto/work/date_du_jour-current.csv Les enregistrements rejettes par le pre-traitement sont stockes dans le fichier : /data/priceminister/pmshare/exploit/stats_auto/work/date_du_jour-null.csv Chargement des stats auto dans ORACLE : =========================== pour charger les stats dans la table "consultation_history" du schema "log4j/log4j@GLOB.TITAN" en tant que pmas@titan dans le repertoire : /data/priceminister/pmshare/exploit/stats_auto executer le script: ./stats_auto.sh load les logs du chargement sqlldr sont disponible dans : /data/priceminister/pmshare/exploit/stats_auto/work/log Remarques : ======== * L'ensemble de la chaine a ete teste et fonctionne correctement. cependant il y a beaucoup de doublon dans la table "consultation_history" car les fichiers de log ont ete stockes en double (Ranto a corrige le pb et il est entrain de faire le menage ). Il faut donc re-proceder a un cycle complet pour avoir des donnees coherantes dans "consultation_history" ce qui sera fait le 5 Jan 06 * Il est possible que creer un dblink entre la base OLTP (jupiter) et BW (titan) pour pouvoir consulter la table "consultation_history" depuis l'OLTP |
| Commentaire de Christophe Garcia [ 11/janv./06 17:09 ] |
|
Où en sommes-nous ? Le process de collecte des fichiers et d'import dans la base BI est-il en place ? |
| Commentaire de Edouard Laurent [ 12/janv./06 11:28 ] |
|
Tout fonctionne, ce n'est pas automatise, je fais le chargement a la main actuellement Les donnees "VALIDES" sont disponibles dans consultation_history du schema log4j/log4j@GLOB.TITAN |
| Commentaire de Arnaud Forgues [ 13/janv./06 15:19 ] |
|
Trois points d'améliorations pour le chargement des données pour la V810 : 1/ Afin d'optimiser les calculs de vues matérialisées sur cette table de données brutes (consultation_history), il faudrait ajouter lors du chargement de données (avec le SQL LOADER) une colonne à cette table contenant le premier jour de la semaine de chauqe date de consultation : --> c'est à dire : TRUNC(:consultation_date, 'D') Pour les données déjà chargée il faudra : - soit vider la table et recharger toutes les données avec cette nouvelle pseudo colonne - soit passer les scripts suivants : CONNECT log4j/log4j@&INSTANCE ALTER TABLE consultation_history ADD week_start_date DATE; UPDATE consultation_history SET week_start_date = TRUNC(consultation_date, 'D'); COMMIT; ALTER TABLE consultation_history MODIFY week_start_date NOT NULL; 2/ Afin d'éviter les problèmes de lignes erronées dues à la présence d'un ";" dans un des champs chargés, on va remplacer le séparateur par un "§" (le "paragraphe" situé sur la touche "!" avec un "Shift") 3/ Enfin d'afin d'éviter les doublons pour identifier un véhicule donné, il faudrait s'assurer que le Charset est correct sur tous les SA en PROD car on a pu constater l'erreur suivante sur un modèle BMW qui apparaissait des deux manières suivantes : "Série 5" et "S¿rie 5" Merci !!! |
| Commentaire de Arnaud Forgues [ 16/janv./06 18:58 ] |
|
La partie mise à jour des données déjà chargée du point 1/ a
déjà été faite par Patrick et moi-meme lors du passage des scripts des
pré-déploiement V810. Il reste donc l'ajout de la nouvelle colonne dans le script du SQLLOADER et également les points 2/ et 3/ |
| Commentaire de Edouard Laurent [ 17/janv./06 18:00 ] |
|
voila le control_file utilise pour charger les donnees : load data infile '$WORK_DIR/$TODAY-current.csv' append into table consultation_history fields terminated by "§" trailing nullcols ( page_type, seller_type, seller_account_id, manufacturer, model, version, cpl_product_id, consultation_date timestamp 'YYYY-MM-DD HH24:MI:SS.FF3', manufacturer_key, model_key, version_key, has_photo, has_warranty, brand_id INTEGER EXTERNAL TERMINATED BY "\r", week_start_date "TRUNC(TO_TIMESTAMP(:consultation_date,'YYYY-MM-DD HH24:MI:SS.FF3'), 'D')" |
| Commentaire de Patrick Pereira [ 19/janv./06 19:12 ] |
|
REFRESH DES VM: ---------------------------- A la fin du load des données, en tant que log4j passer la commande : exec REFRESH_STATS_OLTP_VM; et voilà. Cette procédure met à jours les vm sur titan et sur jupiter. |
| Commentaire de Christophe Garcia [ 20/janv./06 12:15 ] |
|
Edouard, Le JIRA Est-ce que c'est pris en compte ? |
| Commentaire de Edouard Laurent [ 25/janv./06 09:56 ] |
|
Nous avons fait la modification suite au mini-deploiment.
Les 3 colonnes on etait place en status UNUSED dans la table
consultatation_history. Il faudrat proceder a un suppression definitive des ces colonnes dans le futur. J'ai tester integralement la chaine stat auto ce matin : "pmas@titan" : dans le rep "/data/priceminister/pmshare/exploit/stats_auto" ./stats_auto.sh collect : recupere et concataine les logs auto des serveurs JBOSS : ras, plus aucune ligne avec des NULL ./stats_auto.sh load : charge les donnees dans la table consultation_history : sur 2 984 075 lignes chargees, 6151lignes rejetees, en grande partie a cause de "version_key" non existant ./stats_auto.sh refresh : met a jour les VM : ras Je pense que l'on peut automatiser le processus. Fait de maniere quotidienne il faut prevoir ~ 20 Min pour l'ensemble OK pour le dev ? |
| Commentaire de Edouard Laurent [ 27/janv./06 09:59 ] |
|
Pour Manu : voici un extrait des lignes rejettees par le loader : Pour info, Hier : ==== Total logical records read: 542040 Total logical records rejected: 37283 Aujourd'hui : ======== Total logical records read: 560034 Total logical records rejected: 1123 Extrait des bad d'hier : ============== liste_annonces§part§2610047§7377877§2006-01-25 15:16:10.803§PM04000443§PM07992714§§0§0§0 liste_annonces§part§4775233§7175950§2006-01-25 15:28:35.089§M126732§PM00490443§§1§0§0 liste_annonces§part§4687193§6968151§2006-01-25 15:28:35.09§M126732§PM07991362§§0§0§0 liste_annonces§part§4712576§7028811§2006-01-25 15:33:21.873§PM07991718§PM07991840§§0§0§0 liste_annonces§part§4712576§7028811§2006-01-25 15:34:16.438§PM07991718§PM07991840§§0§0§0 liste_annonces§part§2610047§7377877§2006-01-25 15:35:30.742§PM04000443§PM07992714§§0§0§0 liste_annonces§part§2610047§7377885§2006-01-25 15:36:03.301§PM04000443§PM07993204§§0§0§0 liste_annonces§part§2927512§6628676§2006-01-25 15:36:36.86§PM04000443§PM08120444§§0§0§0 liste_annonces§part§4755962§7135128§2006-01-25 15:44:22.79§PM07989541§PM08007902§§0§0§0 liste_annonces§part§4755962§7135128§2006-01-25 15:44:22.814§PM07989541§PM08007902§§0§0§0 liste_annonces§part§4755962§7135128§2006-01-25 15:44:24.454§PM07989541§PM08007902§§0§0§0 liste_annonces§part§4755962§7135128§2006-01-25 15:44:24.738§PM07989541§PM08007902§§0§0§0 liste_annonces§part§4755962§7135128§2006-01-25 15:45:05.005§PM07989541§PM08007902§§0§0§0 liste_annonces§part§4703030§6992921§2006-01-25 16:16:36.136§PM07876863§PM07987282§§0§0§0 liste_annonces§part§2610047§7377877§2006-01-25 16:37:17.819§PM04000443§PM07992714§§0§0§0 liste_annonces§part§4742657§7100876§2006-01-25 16:55:54.898§PM07944145§K07993§§0§0§0 liste_annonces§part§949043§7134255§2006-01-25 16:55:54.898§PM07944145§K07993§§1§0§0 liste_annonces§part§4755962§7135128§2006-01-25 17:00:40.155§PM07989541§PM08007902§§0§0§0 liste_annonces§part§4693903§7137723§2006-01-25 17:06:02.57§PM07714853§K02480§§0§0§0 Extrait des bad d'aujourd'hui : =================== liste_annonces§pro§9402304§16992429§2006-01-26 14:58:02.526§M126732§PM07991365§§1§0§0 liste_annonces§pro§4489714§9051027§2006-01-26 14:59:13.94§PM07989642§PM07989801§§0§0§0 liste_annonces§pro§9402304§16992429§2006-01-26 14:59:41.654§M126732§PM07991365§§1§0§0 liste_annonces§pro§4489714§9051027§2006-01-26 15:01:32.48§PM07989642§PM07989801§§0§0§0 liste_annonces§part§4731898§7048225§2006-01-26 16:11:42.875§PM07993538§PM08072367§§0§0§0 liste_annonces§part§4733877§7121663§2006-01-26 16:11:42.891§PM07993356§K04180§§0§0§0 liste_annonces§part§4756570§7136451§2006-01-26 17:23:02.027§PM04000443§M110394§§0§0§0 liste_annonces§part§4693903§7137723§2006-01-26 17:25:01.78§PM07714853§K02480§§0§0§0 |
| Commentaire de Christophe Garcia [ 31/janv./06 16:10 ] |
|
Edouard, Je vais ouvrir un autre JIRA pour le pb que tu signales ci-dessus. Merci de fermer ce JIRA si la tâche "collecte de stats auto" est complètement implémentée de ton côté. |
| Commentaire de Sébastien Tournay [ 31/janv./06 17:37 ] |
|
Edouard, On vient de recharger ce matin les données du au fait que le DW n'était pas synchronisé au moment du lancement du CRON. Il faut prévoir ce cas de figure pour relancer automatiquement (au même titre que ce que nous faisons avec EMV, partnership..). On constate également toujours de plusieurs lignes dans le fichier bad. Je voudai bien comprendre à quoi cela correspond. ESt-ce normal ? Devons-nous nous en inquiéter ? |
| Commentaire de Arnaud Forgues [ 31/janv./06 17:51 ] |
|
Il peut s'agir soit : - des lignes de logs archivées a moitié lors du redémarrage des serveurs (donc autant qu'il y a de SA) - des lignes de logs des véhicules qui n'ont pas d'attribut "En-tete / Version" (voir le JIRA APP-7232) ==> vous n'avez donc pas a vous en inquieter - autre ??? Arnaud |
| Commentaire de Christophe Garcia [ 13/févr./06 19:09 ] |
| OK pour la collec des stats en automatique |
[DEC-201] création d'un rapport permettant de suivre l'évolution du nombre de parrain Création: 15/déc./05 18:25 Mise à jour: 14/sept./07 14:18 Résolue: 23/oct./06 12:33 |
|
| Etat: | Fermé |
| Projet: | Reporting |
| Composants: | Marketing |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Nouvelle fonctionnalité | Priorité: | Majeur |
| Rapporteur: | Thomas Beylot | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | 4 heures | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | 4 heures | ||
| Description |
|
Bonjour, Comme nous allons améliorer le système de parrainage, il me faudrait plus d'indicateurs pour établir sa cohérence et ses performances. En fait, il me manque une donnée essentielle qui est le nombre de parrains PriceMinister. Serait-il possible de créer ce rapport? merci, thomas. |
| Commentaires |
| Commentaire de François Le Lay [ 04/janv./06 13:09 ] |
|
Tu souhaites que ce rapport soit hebdo, quotidien ou mensuel? Pour info au jour d'aujourd'jui, on 39328 parrains et 115363 filleuls, tous types de comptes confondus (inclus donc les comptes de type contact qui n'ont pas été transformés en compte normal suite à un achat.) |
| Commentaire de François Le Lay [ 04/janv./06 17:50 ] |
|
Thomas je mets cette demande en standby jusqu'à ce que tu me
dises précisement les indices dont tu as besoin (type de compte filleul
contact ou normal, dormants ou non, pourcentage et/ou nombre, cumul
et/ou nouveaux filleuls/parrains par jour/mois/année ....) |
| Commentaire de Thomas Beylot [ 19/sept./06 11:48 ] |
|
yo je faisais un pti tour des jira et me suis rendu compte que celui-ci trouvait sa réponse dans un autre (BIN-153) mais je crois que c'est encore Agathe qui le tient. Soit dit en passant ça serait cool si on pouvait le traiter car le parrainage sort avec la prochaine version. Aussi si je pouvais avoir les indicateurs pour voir si les projets qu'on met en place sont efficaces ce serait quand même pas mal :-) voilou, thomas. |
| Commentaire de Agathe Remy [ 19/sept./06 13:59 ] |
|
Hello, En effet, je met ce JIRA en doublon de l'autre. Pour ton information, j'ai plannifier ce projet pour fin 2006. Il sera traité après le projet 1000Mercis lot 1 et le BI Espagne, à savoir en décembre. Cordialement, Agathe |
[BIN-679] [Partners] : Kelkoo Vente : modification modèle de rémunération appel à facture Création: 18/juin/10 16:43 Mise à jour: 13/sept./10 10:05 Résolue: 01/juil./10 10:08 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Nouvelle fonctionnalité | Priorité: | Majeur |
| Rapporteur: | Claire Genty | Attribution: | Agathe Remy |
| Résolution: | Invalid | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour Agathe, Nous sommes entrain de changer de modèle de rémunération pour Kelkoo vente (module spécifique en bas de page du comparateur). Actuellement 2 appels à factures : Ces 2 appels ont pour modèle de rémunération (6¿ membre actif + 5% VA) : ¿ Kelkoo - Appel à facture hebdomadaire ¿ Kelkoo - Appel à facture mensuel Le nouveau modèle sera donc le suivant 0,03¿/ visite source Xiti + 7¿/membre actif à partir du 1er juillet 2010. Pourras-tu modifier les 2 rapports à partir du 10/07? (après envoi de l'appel à facture de juin sur ancien modèle avec VA le 9/07) Merci par avance Claire |
| Commentaires |
| Commentaire de Agathe Remy [ 21/juin/10 17:50 ] |
|
Bonjour Claire, L'ancien modèle de rémunération du rapport était : - 5% du VA capturé TTC frais de port inclus, hors CBV et jors EG - 6 euros par membres actifs Les visites Xiti n'étant pas importées dans BI, nous ne pouvons pas calculer les revenus associés. Le nouvel appel à facture ne doit-il plus se baser que sur le nombre de membres actifs? Plus du tout sur le VA? Merci, Agathe |
| Commentaire de Benoit Tabaka [ 22/juin/10 09:09 ] |
|
De mon côté, la revue du nouveau OI a été réalisé hier. On a effectivement, comme l'indique Claire, un nouveau modèle économique : - un CPC (dont les données sont donc entre les mains de Kelkoo) - un CPA pour tout nouveau membre actif (membre faisant une première mise en vente ou membre faisant un premier achat). Question plus pour Claire : dès lors que l'on donne accès à Xiti à Kelkoo (qui donc a priori peut récupérer les données "nouveau membre"), est-il encore nécessaire que du côté de PM nous fassions un appel à facture ? Avec le précédent modèle éco basé sur un Rev Share, c'était nécessaire. Mais là, ce sont des données que Kelkoo est susceptible de récupérer comme un grand (via ses systèmes pour le CPC ou via Xiti pour le CPA). |
| Commentaire de Claire Genty [ 22/juin/10 11:51 ] |
|
Agathe, Benoit, Effectivement, pas besoin d'appel à facture pour Kelkoo Vente étant donné que tout est basé sur des datas Xiti. Mea culpa :-) Kelkoo va donc récupérer les données via son accès Xiti personnalisé et de mon côté je ferai de même chaque début de mois. Le nouveau modèle de rémunération prend effet le 1/07/2010. Ainsi, l'appel à facture actuel prend fin le 10/07/2010 (dernier appel à facture pour juin). Merci encore Claire |
| Commentaire de Agathe Remy [ 13/sept./10 10:05 ] |
|
Les appels à facture ont bien été désactivés.
Agathe |
[BIN-123] [Parrainage] : Demande de nouveaux rapports Création: 12/juil./06 18:32 Mise à jour: 14/sept./07 17:17 Résolue: 26/avr./07 20:05 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Thomas Beylot | Attribution: | Agathe Remy |
| Résolution: | Invalid | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Brief rapport parrainage.doc
|
||||||||
| Liens des demandes: |
|
||||||||
| Description |
|
hello le projet parrainage est ressorti du fin fond de nulle part, avec une mise en prod prévue pour fin du mois d'août. Aussi je ressors le document en pj, qui récapitule les datas dont j'aurais besoin afin de suivre l'impact des actions qui vont être implémentées. A votre dispo pour en parler et prioriser le cas échéant. merci, thomas. |
| Commentaires |
| Commentaire de Thomas Beylot [ 12/juil./06 18:33 ] |
| voilà le doc, en pj. |
| Commentaire de Agathe Remy [ 26/sept./06 12:16 ] |
| Voir ce qui est disponible dans Customer Followup avec MEZ. |
| Commentaire de Agathe Remy [ 12/déc./06 17:25 ] |
|
Un petit rapport sur les points en suspens sur le rapport de parrainage de Thomas. Le nombre de filleuls total est égal au nombre de filleuls inscrits. Il n'y a pas de filleuls en type contact ! Le nombre de parrains dormants est erroné. Je l'ai donc supprimé du tableau. La requête parait complexe sur BO puisqu'il faut compter le nombre de parrain qui ont déjà des filleuls actifs mais qui n'ont pas parrainé au mois M et qui n'ont pas de filleuls devenus actifs au mois M. Pourtant on a essayé avec Thomas de le résoudre mais mon cerveau devait être en mode : Parrain dormant. |
| Commentaire de Agathe Remy [ 12/déc./06 18:04 ] |
|
Avec Quentin, nous avons vu que les informations de parrain
ne sont pas enregistrées au niveau du compte utilisateur tant que
celui-ci ne s'est pas inscrit au site. Le seul moyen de suivre les parrains potentiels (i.e. n'ayant pas de filleul inscrit) et les filleuls non inscrits est donc de suivre les mails de parrainage envoyé par le site (table FRIEND_MAIL). Or ces informations ne sont pas aujourd'hui disponibles dans BI. Il s'agit d'un vrai projet technique pour insérer ces infos. Thomas, pourrais-tu commenter ce JIRA avec le nom du rapport développé par MEZ et la liste des informations aujourd'hui disponibles dans ce rapport, ainsi que celle des informations manquantes? Merci:-) Agathe |
| Commentaire de Agathe Remy [ 19/janv./07 17:49 ] |
|
Thomas, Je me permets de te relancer afin que tu complètes ce JIRA : nous pourrons ensuite aborder ta nouvelle demande... Merci:-) Agathe |
[DEC-403] Demande de rapport de meilleures ventes par catégorie Création: 26/juil./06 14:44 Mise à jour: 14/sept./07 14:44 Résolue: 02/nov./06 12:12 |
|
| Etat: | Fermé |
| Projet: | Reporting |
| Composants: | Trading |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Emmanuelle Lachamp | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
Hello ! Je voudrais connaitre les meilleures ventes (depuis le debut) pour les categories suivantes puis par type de produits Puericulture vetement femme vetement homme vetement enfant chaussures materiel de sport cosmetiques merci emma |
| Commentaires |
| Commentaire de Agathe Remy [ 02/nov./06 12:12 ] |
|
D'après Pascal, le reporting demandé a été mis en place via 4D en septembre. D'autre part, afin d'éviter de faire le même travail dans 4D et BI, toutes les demandes de reporting doivent être validées au préalable par Pascal. Merci:-) Cordialement, Agathe |
[APP-6526] gros pb sur la base : 100% de cpu, plein de lock sur une requete bien precise Création: 28/nov./05 18:50 Mise à jour: 25/juin/07 18:33 Résolue: 30/nov./05 15:35 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 8.0.8e |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Justin Ziegler | Attribution: | Olivier Bernard |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
utilisateurs pas contents.msg
|
| Site: | Prod |
| Description |
|
PID=17177 BABEL_1 178,53203 5 149
2157321 x SELECT prd_attribute_value_key, value, pattern FRO
1630962956 84BBF304 PID=13738 BABEL_1 149,41118 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=16506 BABEL_1 101,466 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=17845 BABEL_1 192,63649 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=25813 BABEL_1 164,50845 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=14238 BABEL_1 100,63455 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=17076 BABEL_1 47,7141 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=9997 BABEL_1 159,28863 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=16772 BABEL_1 151,2176 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=24733 BABEL_1 110,14413 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=17485 BABEL_1 55,47501 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=14236 BABEL_1 50,35595 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=22146 BABEL_1 189,44120 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=23716 BABEL_1 99,35754 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=16500 BABEL_1 23,6491 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=20144 BABEL_1 83,46235 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=17103 BABEL_1 128,53447 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=17324 BABEL_1 38,61365 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=29852 BABEL_1 67,45110 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=26903 BABEL_1 107,19358 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=15615 BABEL_1 84,47373 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=23423 BABEL_1 105,22393 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=3844 BABEL_1 43,25069 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=8189 BABEL_1 141,42510 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=17360 BABEL_1 165,6371 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=24696 BABEL_1 77,23254 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=20198 BABEL_1 94,61306 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=10049 BABEL_1 48,29287 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=17222 BABEL_1 193,39519 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=28761 BABEL_1 37,55935 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=9080 BABEL_1 103,30903 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=16850 BABEL_1 202,2248 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=4930 BABEL_1 68,36171 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=8783 BABEL_1 174,44537 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=11898 BABEL_1 172,53020 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=28384 BABEL_1 70,31866 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=23388 BABEL_1 45,57739 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=2562 BABEL_1 56,20278 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=18442 BABEL_1 183,54034 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=22146 BABEL_1 189,44120 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=17845 BABEL_1 192,63649 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=17241 BABEL_1 71,21778 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=23231 BABEL_1 133,41904 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=5782 BABEL_1 145,59403 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=16772 BABEL_1 151,2176 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=18320 BABEL_1 109,28425 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=17485 BABEL_1 55,47501 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=18309 BABEL_1 173,5228 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=14238 BABEL_1 100,63455 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=25813 BABEL_1 164,50845 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=16506 BABEL_1 101,466 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=26702 BABEL_1 32,47727 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=15615 BABEL_1 84,47373 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=11263 BABEL_1 136,454 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=23423 BABEL_1 105,22393 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=12089 BABEL_1 27,4195 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=16850 BABEL_1 202,2248 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=17188 BABEL_1 121,62816 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=30981 BABEL_1 144,51033 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=16731 BABEL_1 122,41911 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=5193 BABEL_1 169,16297 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=6506 BABEL_1 66,24550 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=17773 BABEL_1 160,29135 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=29852 BABEL_1 67,45110 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=26903 BABEL_1 107,19358 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=2059 BABEL_1 25,47793 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=8613 BABEL_1 139,42022 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=17076 BABEL_1 47,7141 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=9997 BABEL_1 159,28863 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=16367 BABEL_1 200,638 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=25272 BABEL_1 102,55080 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=24696 BABEL_1 77,23254 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=20142 BABEL_1 117,17580 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=20198 BABEL_1 94,61306 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=10049 BABEL_1 48,29287 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=20146 BABEL_1 157,50460 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=28761 BABEL_1 37,55935 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=23578 BABEL_1 171,14149 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=9080 BABEL_1 103,30903 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=9994 BABEL_1 80,33162 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=18294 BABEL_1 81,61824 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO [pmas@hercule priceminister]$ ./pmscripts/pmdatabase/utils/dba/report-expensive-session.sh glob | grep PID PID=17179 BABEL_1 57,29784 -59154 1271 30311 x /* AttributeValueDependanceQuery */ SELECT /* 2214375796 89B81844 PID=23231 BABEL_1 133,41904 -59154 1271 30311 x /* AttributeValueDependanceQuery */ SELECT /* 2214375796 89B81844 PID=28761 BABEL_1 37,55935 -59154 1271 30311 x /* AttributeValueDependanceQuery */ SELECT /* 2214375796 89B81844 PID=30447 16,1 0 0 15665 x SELECT REOPEN_SECS FROM v$archive_dest WHERE dest_ 2144221516 8C833270 PID=21568 BABEL_1 24,64579 3 0 470539630 x SELECT DOCID FROM "PRODUCT_1"."DR$PRODUCT_IMX$K" W 1638776572 84F2F4F0 PID=30422 1,1 3 1 37555 x select o.owner#,o.name,o.namespace,o.remoteowner,o 431456802 79FF1DC4 PID=30438 9,1 3 1 37555 x select o.owner#,o.name,o.namespace,o.remoteowner,o 431456802 79FF1DC4 PID=18442 BABEL_1 183,54034 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=19607 BABEL_1 81,61859 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=16750 BABEL_1 182,25365 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=19965 BABEL_1 58,3562 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=8787 BABEL_1 177,9524 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=29852 BABEL_1 67,45110 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=21560 BABEL_1 14,31581 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=17082 BABEL_1 118,31900 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=3844 BABEL_1 43,25069 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=25198 BABEL_1 44,37159 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=20008 BABEL_1 62,3765 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=17188 BABEL_1 121,62816 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=19796 BABEL_1 130,25651 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=23578 BABEL_1 171,14149 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=9080 BABEL_1 103,30903 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=20135 BABEL_1 149,42752 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=17103 BABEL_1 128,53447 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=18593 BABEL_1 39,18982 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=19771 BABEL_1 45,59262 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=23720 BABEL_1 28,44327 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=17076 BABEL_1 47,7141 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=20101 BABEL_1 78,17839 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=18511 BABEL_1 64,64551 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304 PID=26903 BABEL_1 107,19358 6 21 6348975 x SELECT purchase_id, creation_date, change_date, pc 1065709384 87C5AB7C PID=30436 8,1 12 0 15099 x select con#,type#,condlength,intcols,robj#,rcon#,m 1937775682 79FCFC1C PID=20643 BABEL_1 191,23815 64 24 931621 x UPDATE PRODUCT SET IS_AVAILABLE = SIGN(:B14 + :B13 2980372004 82FFD1C0 PID=20361 BABEL_1 134,1017 71 8 19797093 x /* AttributeExtendedInfoQuery */ SELECT prd_a 1368569202 87506C9C PID=20146 BABEL_1 157,50460 71 8 19797093 x /* AttributeExtendedInfoQuery */ SELECT prd_a 1368569202 87506C9C PID=17392 BABEL_1 76,815 103 61 908500 x UPDATE ADVERT SET PRD_BEST_PRICE = :B8 , PRD_ADV_C 2094161026 82FFCD04 PID=8785 BABEL_1 120,10154 3950 3045 3 x /* ProductNavigationQuery::PowerCount */ SELECT 2817342393 8B745860 PID=24733 BABEL_1 110,14413 4471 3703 2 x /* ProductNavigationQuery::PowerCount */ SELECT 2355610782 8F95B408 PID=20415 BABEL_1 13,42036 4582 1086 427 x /* ProductNavigationQuery::PowerCount */ SELECT 3111732486 8248B0C8 PID=5782 BABEL_1 145,59403 4907 215 39459 x /* ProductNavigationQuery::Search */ SELECT / 1461890885 8B34EE34 PID=16367 BABEL_1 200,638 5376 365 40903 x /* ProductNavigationQuery::Search */ SELECT / 1123785949 930E5B28 PID=22146 BABEL_1 189,44120 5951 1824 964 x /* ProductNavigationQuery::PowerCount */ SELECT 3823848925 8AB2DD98 PID=20033 BABEL_1 179,24965 6461 3943 82 x /* ProductNavigationQuery::PowerCount */ SELECT 1179260981 96EF31AC PID=20142 BABEL_1 117,17580 9108 46 645 x /* ProductNavigationQuery */ SELECT /*+ INDEX 1700859058 91767B5C PID=18569 BABEL_1 42,53789 30491 1028 57943 x /* ProductNavigationQuery::Search */ SELECT / Arret de tous les batch appli : le pb persiste. La requete en question : SELECT prd_attribute_value_key, value, pattern FROM PRD_ATTRIBUTE_VALUE WHERE prd_attribute_value_key=:1 FOR UPDATE Pleins de lock bloquants sur la base. Pleins de sessions actives pour tous les serveurs applis. |
| Commentaires |
| Commentaire de Justin Ziegler [ 28/nov./05 18:51 ] |
|
Les paniers passent malgre tous ! Charge sur la base : 40 vmstat 1 procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 45 6 176 413792 155068 28228092 0 0 2 3 0 4 26 9 48 17 51 8 176 432480 155076 28221584 0 0 4148 1124 6956 4523 76 24 0 0 34 8 176 431904 155260 28226080 0 0 4792 652 8047 4474 77 23 0 0 38 8 176 439200 155456 28230304 0 0 5420 896 8640 5056 78 22 0 0 40 15 176 416608 155540 28234900 0 0 5100 1004 6734 3938 78 22 0 0 44 10 176 404832 155696 28240464 0 0 4672 3020 6413 3854 77 23 0 0 |
| Commentaire de Justin Ziegler [ 28/nov./05 18:52 ] |
|
iostat -x 1 avg-cpu: %user %nice %sys %iowait %idle 73.91 0.00 26.09 0.00 0.00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util cciss/c0d0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 cciss/c0d1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sda 0.00 14.85 50.50 14.85 847.52 237.62 423.76 118.81 16.61 0.42 6.64 5.06 33.07 sdb 0.00 16.83 154.46 16.83 2518.81 269.31 1259.41 134.65 16.28 1.23 7.90 3.84 65.84 sdc 0.00 8.91 49.50 8.91 752.48 142.57 376.24 71.29 15.32 0.41 8.02 5.10 29.80 sdd 0.00 15.84 80.20 15.84 1267.33 253.47 633.66 126.73 15.84 0.49 5.86 4.06 39.01 sde 0.00 21.78 65.35 23.76 1053.47 364.36 526.73 182.18 15.91 0.55 6.77 4.18 37.23 sdf 0.00 25.74 87.13 23.76 1504.95 396.04 752.48 198.02 17.14 0.73 6.76 4.41 48.91 sdg 0.00 7.92 84.16 7.92 1322.77 126.73 661.39 63.37 15.74 0.71 7.87 5.29 48.71 sdh 0.99 44.55 110.89 60.40 2067.33 831.68 1033.66 415.84 16.92 0.44 2.92 1.28 21.98 sdi 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sdj 0.00 7.92 0.00 29.70 0.00 79.21 0.00 39.60 2.67 1.05 101.77 1.67 4.95 sdk 0.00 5.94 0.00 5.94 0.00 95.05 0.00 47.52 16.00 0.00 0.50 0.50 0.30 avg-cpu: %user %nice %sys %iowait %idle 73.61 0.00 26.39 0.00 0.00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util cciss/c0d0 0.00 1.00 0.00 2.00 0.00 24.00 0.00 12.00 12.00 0.00 0.50 0.50 0.10 cciss/c0d1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sda 0.00 32.00 37.00 32.00 704.00 512.00 352.00 256.00 17.62 0.27 3.96 3.19 22.00 sdb 0.00 38.00 144.00 38.00 3048.00 608.00 1524.00 304.00 20.09 0.79 4.31 3.23 58.70 sdc 0.00 29.00 69.00 29.00 1320.00 464.00 660.00 232.00 18.20 0.41 4.16 3.36 32.90 sdd 0.00 43.00 42.00 43.00 736.00 688.00 368.00 344.00 16.75 0.29 3.41 2.67 22.70 sde 0.00 37.00 56.00 35.00 848.00 576.00 424.00 288.00 15.65 0.35 3.86 3.22 29.30 sdf 0.00 37.00 64.00 37.00 1232.00 592.00 616.00 296.00 18.06 0.39 3.77 3.40 34.30 sdg 0.00 23.00 35.00 23.00 584.00 368.00 292.00 184.00 16.41 0.21 3.69 3.34 19.40 sdh 0.00 47.00 45.00 89.00 648.00 1088.00 324.00 544.00 12.96 0.25 1.87 0.87 11.70 sdi 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sdj 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sdk 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 |
| Commentaire de Justin Ziegler [ 28/nov./05 18:52 ] |
| donc : pas de saturation disque |
| Commentaire de Justin Ziegler [ 29/nov./05 16:29 ] |
| A plusieurs reprise, j'ai tue les sessions a problemes, mais de nouvelles arrivaient sans cesse. |
| Commentaire de Olivier Bernard [ 30/nov./05 12:18 ] |
|
L'Ejb CMP AttributeValueBusiness est en mode de lock
pessimiste comme la plupart des autres entités sur PriceMinister. Dans ce cas précis, on ne modifie que très rarement ces éléments : par l'import CNET, ou manuellement par le BO. On peut donc supprimer le lock pessimiste sur cet EJB Entité sans risque, afin d'enlever les locks for Update. |
| Commentaire de Olivier Bernard [ 30/nov./05 15:35 ] |
| Suppression du lock pessimiste via le fichier build.xml. |
| Commentaire de Laurent Merlet [ 08/déc./05 11:11 ] |
|
Vu avec Olivier Bernard testé en production |
[DEC-22] Homogénéisation du calcul du volume d'affaires Création: 19/juil./05 15:18 Mise à jour: 10/sept./07 17:43 Résolue: 17/août/06 11:19 |
|
| Etat: | Fermé |
| Projet: | Reporting |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Cosmétique |
| Rapporteur: | François Le Lay | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
homogéniser le cacul du volume d'affaire pour les co-brandings, les trackings et les PurchaseByTracking.
|
| Commentaires |
| Commentaire de François Le Lay [ 17/août/06 11:19 ] |
| inhérent au Lot Marketing BI |
[APP-7057] IMPORT POLK: plusieurs valeurs en base pour le champ En-tête / Version Création: 16/janv./06 17:19 Mise à jour: 29/oct./09 10:12 Résolue: 26/oct./09 12:26 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Base de données |
| Affecte la/les version(s): | 8.1.0 |
| Version(s) corrigée(s): | 56.0.0 (TX-J) |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Patrick Condevaux | Attribution: | Emeric Teil |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Site: | Integ | ||||||||
| Classif1: | BP | ||||||||
| Classif2: | RBP - attribut | ||||||||
| Projets PM archivés: | AUTO : Nettoyage | ||||||||
| Description |
|
En consultant certain produit (par exemple Audi A6 2.5 TDi
Pack Qtro. Avt BM6) on a 3 valeurs correspondant au champ En-tête /
Version (apparement du a plusieurs import polk) Cela pose un problème lors de la génération des statistiques des vendeurs auto Une unique valeur devrait exister pour ce champ. |
| Commentaires |
| Commentaire de Arnaud Forgues [ 16/janv./06 18:39 ] |
|
On rencontre ce problème en INTEG. Est-ce le cas également en PROD ? Je crois qu'un néttoyage avait été fait sur la base auto de PROD !? D'autre part s'agit-il de problème avec les fichiers d'imports POLK ou du programme d'import lui-meme |
| Commentaire de Patrick Condevaux [ 17/janv./06 11:00 ] |
|
Le probleme est le même en prod. Voir par exemple les statistiques auto de LABELCARS Ce probleme apparait sur environ 3800 annonces encore en vente ayant de 2 à 6 valeurs pour le champ entete/version |
| Commentaire de Marc Cacheiro [ 17/janv./06 17:59 ] |
| après discussion avec Quentin, il faut identifier la cause de la génération d'attributs multiples : imports POLK, imports pro, etc... (non seulement sur les versions mais sur tous les attributs), afin de chercher une solution qui pourra s'appliquer à tous les problèmes que cette anomalie peut soulever. |
| Commentaire de Arnaud Forgues [ 18/janv./06 15:12 ] |
|
Après discussion avec Martin, le problème provient de la
mauvaise gestion de collision dans l'import, dûe initialement a des
données pourries dans les fichiers polk. Pour règler ce problème il faudrait mettre en place cette notion de gestion de collision. Cela est donc intrinsequement lié au chantier refonte de la base produit. Je transmet donc le bug à Olivier. NB1 : Pour plus d'infos sur les chiffres exacts d'attributs multiples sur fiches produits, on peut demander à Francois de l'equipe BI (qui a déjà réalisé un rapport la dessus) NB2 : Jusqu'a présent, ce problème était connu mais n'avais pas d'impact génant sur l'application. Le cas présent des stats auto pourrait remonter la priorité de la refonte produit ... |
| Commentaire de Quentin de Chivré [ 18/janv./06 15:26 ] |
|
Donc en fait il faut que je me leve , que j'aille voir
Francois et que je lui demande son rapport si je veux plus
d'informations ? Je ne vois pas pourquoi tu transmet ca a Olivier (a Martin d'ailleurs) le pb reste critique sur les stats auto. |
| Commentaire de Arnaud Forgues [ 18/janv./06 16:18 ] |
|
Concernant les chiffres de Francois, il a simplement 3
rapport sur les marques, modeles et versions multiples qui avaient été
codé lors du choix de la base polk en juin dernier. Pour être précis sur l'attribut "En-tete / Version", il y a 5500 annonces avec plus d'un attribut dont 2800 annonces actives (sur un total de 45 000 annonces actives !!). J'ai demandé à Francois un rapport plus général pour tout attribut voiture : En ce qui concerne les stats auto, on va mettre en place une solution temporaire étant donné que la solution refonte base produit n'est pas immédiate. Je laisse donc ce bug à Olivier pour la solution de fond et j'ouvre un autre bug à Manu pour les stats auto : |
Réinstallation de POMERY
(EXP-784)
|
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | Sébastien Tournay | Attribution: | Xiaoming Du |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Description |
|
dès la mise à disposition du nouveau POMERY (en principe
semaine prochaine) par PAP, installer MINITOR sur ce serveur avec un
profil BDD.
|
| Commentaires |
| Commentaire de Xiaoming Du [ 18/janv./06 19:13 ] |
| un nouveau profile a été créé dans minitord pour BI. Pour le moment, il a les meme modules que profile BDD |
| Commentaire de Sébastien Tournay [ 19/janv./06 09:42 ] |
| Très bien. Il faut penser à mettre à jour le wuickview interne pour suivre son profil. Quels sont les alertes activées sur le profil de pomery ? |
| Commentaire de Xiaoming Du [ 31/janv./06 19:21 ] |
|
http://bo.pm.lan/stats/mrtg/pommery/index.html les supervisions de pommery est en place.Les alertes: diskuse, nocrond, nooraproc, dbconnect sont activées sur pommery. |
[EXP-380] Eradication de la présence de /COVER Création: 21/nov./05 12:49 Mise à jour: 25/juin/07 18:54 Résolue: 15/févr./06 15:54 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Evolution |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Sébastien Tournay | Attribution: | Antoine Koener |
| Résolution: | Corrigé | ||
| Estimation restante: | 0 minutes | ||
| Temps consacré: | 10 minutes | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
cover_15_dec_05.txt
fichier_cover_trc_15_dec_05.txt
|
||||||||
| Liens des demandes: |
|
||||||||
| Description |
|
Tu peux nous dire si on constate toujours des requêtes sur /cover dans les logs ? Sommes-nous certains que tout est migré sur /photo ? Cela vaut le coup de refaire une passe au niveau d'APACHE. Si il reste des requêtes, il faut identifier les coupbles ;-) |
| Commentaires |
| Commentaire de Serge Delabrosse [ 25/nov./05 15:05 ] |
|
le 22 NOV 05: =========== On constate encore des appel à cover via speedera ou les comparateurs img.priceminister.com 206.65.191.206 - - [22/Nov/2005:01:46:40 +0100] "GET /cover/82147030 HTTP/1.0" 200 3149 "http://achat.ebuyclub.com/Comparateur/PriceMinister-Sonorisation-Automobile-Autre-Constructeur-Sonorisation-Automobile.htm" "swcd/5.2.0040" m6.priceminister.com 62.23.27.114 - - [22/Nov/2005:01:47:01 +0100] "GET /cover/523568 HTTP/1.1" 200 67862 "-" "libwww-perl/5.65" m6.priceminister.com 212.23.167.24 - - [22/Nov/2005:01:47:18 +0100] "GET /cover/523568 HTTP/1.1" 200 67862 "-" "libwww-perl/5.65" img.priceminister.com 212.162.1.214 - - [22/Nov/2005:01:47:22 +0100] "GET /cover/134783630 HTTP/1.0" 200 6250 "-" "swcd/5.2.0040" img.priceminister.com 212.162.1.214 - - [22/Nov/2005:01:47:25 +0100] "GET /cover/134267030 HTTP/1.0" 200 4387 "http://images.google.com.br/imgres?imgurl=http://priceminister.speedera.net/img.priceminister.com/cover/134267030&imgrefurl=http://www.priceminister.com/navigation/default/category/113216/l1/U/noicon/false&h=130&w=129&sz=5&tbnid=dXLahFh7VxIJ:&tbnh=85&tbnw=84&hl=pt-BR&prev=/images%3Fq%3Dlotr%2Bspectre%26svnum%3D10%26hl%3Dpt-BR%26lr%3D%26sa%3DG&frame=small" "swcd/5.2.0040" img.priceminister.com 82.225.39.112 - - [22/Nov/2005:01:47:25 +0100] "GET /cover/146039430 HTTP/1.1" 200 2998 "http://www.priceminister.com/trc/casques-2.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; fr) Opera 8.50" i www.priceminister.com 212.195.196.78 - - [22/Nov/2005:01:49:47 +0100] "GET /navigation/default/category/104037/noicon/false/rank/2341014B1964014B14238201825A73642801140169735F2864696E146401F4F3F1F1F3F8F60001010201010102010101010201010100270101020102010101010101010101020101010101010100 HTTP/1.1" 200 11388 "http://images.google.fr/imgres?imgurl=http://priceminister.speedera.net/img.priceminister.com/cover/142608530&imgrefurl=http://www.priceminister.com/navigation/default/category/104037/noicon/false/rank/2341014B1964014B14238201825A73642801140169735F2864696E146401F4F3F1F1F3F8F60001010201010102010101010201010100270101020102010101010101010101020101010101010100&h=130&w=129&sz=5&tbnid=AbLgFxZB6scJ:&tbnh=85&tbnw=84&hl=fr&start=2&prev=/images%3Fq%3Ddoc%2Bgyneco%2Bla%2Bclinique%26svnum%3D10%26hl%3Dfr%26lr%3D%26rls%3DGGLD,GGLD:2005-16,GGLD:fr%26sa%3DG" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" www.priceminister.com 69.134.92.11 - - [22/Nov/2005:01:50:38 +0100] "GET /navigation/search/category/search_clothing/keyword/jordan/ss/70 HTTP/1.1" 200 8528 "http://images.google.com/imgres?imgurl=http://priceminister.speedera.net/img.priceminister.com/cover/164802130&imgrefurl=http://www.priceminister.com/navigation/search/category/search_clothing/keyword/jordan/ss/70&h=100&w=130&sz=4&tbnid=5JqfT0pWtKMJ:&tbnh=65&tbnw=85&hl=en&start=173&prev=/images%3Fq%3DAir%2Bjordans%26start%3D160%26svnum%3D10%26hl%3Den%26lr%3D%26sa%3DN" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" img.priceminister.com 206.65.191.206 - - [22/Nov/2005:01:50:39 +0100] "GET /cover/164802130 HTTP/1.0" 200 3662 "http://images.google.com/imgres?imgurl=http://priceminister.speedera.net/img.priceminister.com/cover/164802130&imgrefurl=http://www.priceminister.com/navigation/search/category/search_clothing/keyword/jordan/ss/70&h=100&w=130&sz=4&tbnid=5JqfT0pWtKMJ:&tbnh=65&tbnw=85&hl=en&prev=/images%3Fq%3DAir%2Bjordans%26start%3D160%26svnum%3D10%26hl%3Den%26lr%3D%26sa%3DN&frame=small" "swcd/5.2.0040" img.priceminister.com 216.200.68.7 - - [22/Nov/2005:01:50:57 +0100] "GET /cover/51424030 HTTP/1.0" 200 8760 "-" "swcd/5.2.0040" img.priceminister.com 212.162.1.214 - - [22/Nov/2005:01:59:22 +0100] "GET /cover/116260230 HTTP/1.0" 200 12432 "http://images.google.ca/imgres?imgurl=http://priceminister.speedera.net/img.priceminister.com/cover/116260230&imgrefurl=http://www.priceminister.com/offer/buy/2309763/sort0&h=130&w=105&sz=13&tbnid=GLDHAodYj6IJ:&tbnh=85&tbnw=68&hl=en&prev=/images%3Fq%3Dde%2Btom%2Btom%2Bet%2Bnana%26start%3D40%26svnum%3D10%26hl%3Den%26lr%3D%26sa%3DN&frame=small" "swcd/5.2.0040" img.priceminister.com 83.152.201.141 - - [22/Nov/2005:01:59:30 +0100] "GET /cover/165625730 HTTP/1.1" 200 5157 "http://www.priceminister.com/trc/118366-1.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" @ [Wed Nov 23 14:04:26 2005] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (961): Can't receive the res ponse message from tomcat, network problems or tomcat is down (10.150.28.70:8009), err=-104 |
| Commentaire de Edouard Laurent [ 25/nov./05 15:14 ] |
| http://pricejira.lan/browse/EXP-386 |
| Commentaire de Emmanuel Benmussa [ 13/déc./05 18:30 ] |
|
j'ai encore des images en cover dans les pages TRC , spécial référencement. elles ont été modifées et les images cover ont été remplacées par photo (avec l'id qui va bien) en production après le déploiement de la v8.09. Emmanuel |
| Commentaire de Sébastien Tournay [ 14/déc./05 15:31 ] |
| Serge tu peux faire du suivi la dessus suite au déploiement de ce matin ? Vaut aussi valider avec Ranto qu'il avait bien mis en place les nouvelles pages /trc |
| Commentaire de Serge Delabrosse [ 15/déc./05 16:43 ] |
|
le 15 dec 05 à 16h37 sur phaeton on observait encore 0,31 % de cover du à des user agent "hbtools" ou "swcd" voir fichiers joints . grep "cover" vaccess_log >/data/chrootapache/pmshare/vaccess_log_15_dec_cover.txt un examen complémentaire est possible sur le fichier data/chrootapache/pmshare/vaccess_log_15_dec_cover.txt ============ ANNEXE ==================== [adminpm@phaeton logs]$ grep "cover" vaccess_log | wc -l 11163 ================================================== [adminpm@phaeton logs]$ cat vaccess_log | wc -l 3543492 ================================================== ratio = 11163 / 3543492 = 0,31 % |
| Commentaire de Serge Delabrosse [ 15/déc./05 16:46 ] |
| Qu'en penses tu emmanuel ? |
| Commentaire de Serge Delabrosse [ 15/déc./05 16:58 ] |
|
l'appel à trc / cover compte pour 41% des appel cover . [adminpm@phaeton pmshare]$ grep trc vaccess_log_15_dec_cover.txt | wc -l 4663 [adminpm@phaeton pmshare]$ cat vaccess_log_15_dec_cover.txt | wc -l 11254 [adminpm@phaeton pmshare]$ ====================== ANNEXE ==================== img.priceminister.com 81.67.20.211 - - [15/Dec/2005:16:29:14 +0100] "GET /cover/150546430 HTTP/1.1" 200 4016 "http://www.priceminister.com/trc/114762.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)" img.priceminister.com 81.67.20.211 - - [15/Dec/2005:16:29:14 +0100] "GET /cover/82365230 HTTP/1.1" 200 4556 "http://www.priceminister.com/trc/114762.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)" img.priceminister.com 195.101.248.97 - - [15/Dec/2005:16:29:55 +0100] "GET /cover/165965130 HTTP/1.0" 200 26153 "http://www.priceminister.com/trc/114684.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" img.priceminister.com 195.101.248.97 - - [15/Dec/2005:16:29:56 +0100] "GET /cover/82429630 HTTP/1.0" 200 3299 "http://www.priceminister.com/trc/114684.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" img.priceminister.com 195.101.248.97 - - [15/Dec/2005:16:29:56 +0100] "GET /cover/161859930 HTTP/1.0" 200 2535 "http://www.priceminister.com/trc/114684.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" img.priceminister.com 195.101.248.97 - - [15/Dec/2005:16:29:56 +0100] "GET /cover/100474730 HTTP/1.0" 200 2481 "http://www.priceminister.com/trc/114684.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" img.priceminister.com 84.4.76.39 - - [15/Dec/2005:16:29:58 +0100] "GET /cover/135790530 HTTP/1.1" 200 2671 "http://www.priceminister.com/trc/divers-4.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 8.51" img.priceminister.com 84.4.76.39 - - [15/Dec/2005:16:29:58 +0100] "GET /cover/135787530 HTTP/1.1" 200 3640 "http://www.priceminister.com/trc/divers-4.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 8.51" img.priceminister.com 84.4.76.39 - - [15/Dec/2005:16:29:58 +0100] "GET /cover/144508230 HTTP/1.1" 200 7303 "http://www.priceminister.com/trc/divers-4.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 8.51" img.priceminister.com 84.4.76.39 - - [15/Dec/2005:16:29:58 +0100] "GET /cover/144537230 HTTP/1.1" 200 3348 "http://www.priceminister.com/trc/divers-4.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 8.51" img.priceminister.com 84.4.76.39 - - [15/Dec/2005:16:29:58 +0100] "GET /cover/104317530 HTTP/1.1" 200 2404 "http://www.priceminister.com/trc/divers-4.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 8.51" |
| Commentaire de Swan Desportes [ 27/déc./05 16:16 ] |
|
Bonjour, Maintenant que les TRC ont été corrigées et mis en production, il faudrait comprendre d'où viennent les appels de cover restants. Pourrait-on identifier les referers pour savoir quels sont les sites qui font appels à cover et par quel biais ils ont récupéré ces URL ? Merci |
| Commentaire de Antoine Koener [ 23/janv./06 12:09 ] |
|
Dans vaccess_log, je trouve des demandes provenant toujours du user-agent: swcd 75 % viennent du moteur Speedera, swcd est son user-agent. 25 % viennent du cache des images google. Le responsable est donc Speedera, en voici la preuve: (ligne de log reformattée pour des soucis de lecture) croix-rouge.priceminister.com 131.194.93.19 - - [23/Jan/2006:01:58:42 +0100] "GET /navigation/default/category/1360/l1/J/noicon/false HTTP/1.1" 200 9096 "http://images.google.com/imgres?imgurl= ( google images ) http://priceminister.speedera.net/ ( reference d'une page speedera ) img.priceminister.com/cover/77924930&imgrefurl=http://croix-rouge.priceminister.com/navigation/default/category/1360/l1/J/noicon/false &h=130&w=130&sz=6&tbnid=picCqgArxlph3M:&tbnh=85&tbnw=85&hl=en&start=76&prev=/images%3Fq%3DJem%2Bcartoon%26start%3D60%26svnum%3D10%26hl%3Den%26lr%3D%26sa%3DN" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5. 1; SV1)" Speedera continue de nous demander des /cover, visiblement nous le lui donnons, il continue à alimenter google... Est-ce que cette analyse réponds à la question ? |
| Commentaire de Sébastien Tournay [ 25/janv./06 16:40 ] |
|
On pourrait bloquer le user-agent de speedera pour
l'empécher de crawler ? Pour ce qui concerne GOOGLE, j'ai un peu
l'impression qu'il faut attendre sa mise à jour. Je viens de regarder sur les interfaces d'admin de SPEEDERA, nous n'avons plus accès à leurs logs pour voir quelles pages faisaient encore référence à leurs caches. |
| Commentaire de Antoine Koener [ 15/févr./06 15:54 ] |
| On ne controle pas les caches extérieurs. |
[EXP-445] apache : augmentation des apache errors (Cf courbe minitor) : analyser Création: 30/nov./05 16:56 Mise à jour: 25/juin/07 18:54 Résolue: 27/févr./06 12:43 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Justin Ziegler | Attribution: | Andrei Matyas |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
apacherror-day-261205.png
|
| Description |
|
Nous n'avons pas de bonne raison d'avoir autant d'apache error. Il est important de reduire cette courbe afin qu'elle reste pertinente. La plupart des erreurs proviennent probablement de problemes de dev. Il faut donc les identifier et les faire corriger en postant un jira pour chaque probleme. Il y a peut etre aussi des scan de recherche de trous de secu : on pourrait resoudre cela en mettant des redirections vers la home des urls les plus frequement demandees. |
| Commentaires |
| Commentaire de Sébastien Tournay [ 19/janv./06 15:51 ] |
|
Antoine, Il faudrait suivre cela du coin de l'oeil pour comprendre et isoler ces erreurs. Je viens de remarquer un pic élevé sur la journée d'hier (cf. attachement). ATTENTION car les logs d'erreur sont archivés que 2 jours |
| Commentaire de Justin Ziegler [ 22/févr./06 21:15 ] |
| En fait, j'ai l'impression que le nb d'erreur apache a augmente sensiblement depuis le dernier deploiement... |
| Commentaire de Sébastien Tournay [ 23/févr./06 09:31 ] |
|
Il semble en effet que plusieurs images référencées dans la V811a ne sont pas présentes. Par exemple : * /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V811a/front/brand/camif/images/help/bt1_on.gif.gif * /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V811a/front/brand/www/images/auto/dot_black.gif * /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V811a/front/brand/francemobiles/images/header/tab_over_home.gif * /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V811a/front/brand/www/images/auto/dot_black.gif |
| Commentaire de Antoine Koener [ 23/févr./06 10:46 ] |
|
Voici les erreurs les plus fréquentes: Les stats sont extraites du fichier d'erreurs en cours: c = signifie client denied by server configuration f = signifie file does not exist. c 106 bargain c 106 home c 106 root_baby c 106 root_books c 106 root_clothing c 106 root_electronics c 106 root_games c 106 root_music c 106 root_sport c 106 root_vehicle c 106 root_video c 106 root_white c 106 root_wine c 106 tab_600 c 106 tab_700 c 106 travel f 116 /usr/local/apache/htdocs/pmweb/virtualhost-www/navigation?action=search&ss=15&keyword=Soft&category=search_books&category_sub=-1&t=681061&dinsight=343&kwsl=558413 c 128 /usr/local/apache/htdocs/pmweb/virtualhost-bi/maintenance.asis f 128 /usr/local/apache/htdocs/pmweb/virtualhost-bambinoccasion/maintenance.asis f 129 /usr/local/apache/htdocs/pmweb/virtualhost-www/affiliation/visuels/video/bannieres_468x60/468x60-comedie.gif f 140 /usr/local/apache/htdocs/pmweb/virtualhost-www/MSOffice f 155 /usr/local/apache/htdocs/pmweb/virtualhost-www/_vti_bin f 184 /usr/local/apache/htdocs/pmweb/virtualhost-camif/content/V811a/front/brand/camif/images/help/bt1_on.gif.gif f 856 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V811a/front/brand/camif/images/help/bt1_on.gif.gif c 1698 403.html f 3532 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V811a/front/brand/www/images/auto/dot_black.gif Il y a des fichiers en gif.gif ! f 184 /usr/local/apache/htdocs/pmweb/virtualhost-camif/content/V811a/front/brand/camif/images/help/bt1_on.gif.gif f 856 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V811a/front/brand/camif/images/help/bt1_on.gif.gif |
| Commentaire de Antoine Koener [ 23/févr./06 10:48 ] |
|
Peux tu jeter un oeil sur ces fichiers manquants ? |
| Commentaire de Christophe Garcia [ 24/févr./06 12:08 ] |
| Essentiellement des problèmes de co-branding CAMIF. |
| Commentaire de Bruno Ballester [ 24/févr./06 17:21 ] |
| Certaines images comme http://a526.g.akamai.net/7/526/14067/v1/img.priceminister.com/content/V811a/front/brand/camif/images/help/bt1_on.gif sont bien disponibles cependant il semblerait que soient également hébergées en double sur le serveur des images se terminant par des "gif.gif". |
| Commentaire de Andrei Matyas [ 27/févr./06 12:43 ] |
| Effectivement j'ai identifié des appels des images « gif.gif » dans l'application (pour Camif). J'ai corrigé donc le problème. |
[EXP-425] insertion des attributs dans les flux Création: 28/nov./05 15:15 Mise à jour: 25/juin/07 18:54 Résolue: 01/juin/06 16:09 |
|
| Etat: | Résolu |
| Projet: | Exploitation |
| Composants: | Etude |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Charles Decaux | Attribution: | Edouard Laurent |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Description |
|
Il faudrait être capable de gérer les attributs dans les
flux et donc pour cela de traiter de facon indépendante les livres comme
vu avec Edouard.
|
| Commentaires |
| Commentaire de Alain Bonneaud [ 19/janv./06 16:11 ] |
|
Voir avec le développement et avec l'équipe BI. A priori cela existe déjà pour le hightech dans kelkoo |
[APP-8714] [1euro] développement événements Création: 26/avr./06 18:38 Mise à jour: 25/juin/07 18:37 Résolue: 03/juil./06 18:27 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Paiement |
| Affecte la/les version(s): | 9.0.1 |
| Version(s) corrigée(s): | 9.0.1 |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Martin Iacampo | Attribution: | Renaud Dierickx |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
rapport décisionnel 1euro mini spécification fonctionnelle.doc
|
||||||||||||||||||||
| Liens des demandes: |
|
||||||||||||||||||||
| Description |
|
Pour faire suite à la demande de la DG d'un rapport
décisionnel, voici les événements à développer et à stocker dans la
base. Le développement est pour "dès que possible" (à priori un mini déploiement après la 9.0.0 ou la 9.0.1). Voir pièce jointe, rapport décisionnel 1euro mini spécification fonctionnelle.doc |
| Commentaires |
| Commentaire de Martin Iacampo [ 15/juin/06 16:02 ] |
|
ce serait super intéressant d'avoir ces évènements en place dès l'activation du service, prévu le 28/06 à priori ... même si le développement du rapport prend encore quelque temps, au moins les évènements seront stockés ... est-ce toujours considéré comme un DEV prioritaire ? |
| Commentaire de Arnaud Forgues [ 15/juin/06 16:15 ] |
| C'est en effet dans la besace du Renaud, qui va tenter de le traiter si le temps le lui permet ! |
| Commentaire de Renaud Dierickx [ 19/juin/06 16:57 ] |
|
J'ai créé les évenements sauf celui "départ vers 1euro" car il est plus compliqué que prévu. Etant donné le code freeze de la V901, j'ai livré le premier lot d'évènements. cvs ci -m " dos2unix: converting file CheckoutPay1EuroCom.jsp to UNIX format ... Checking in src/com/babelstore/payment/PaymentConstants.java; /home/cvs/dev/source/src/com/babelstore/payment/PaymentConstants.java,v <-- PaymentConstants.java new revision: 1.6; previous revision: 1.5 done Checking in src/com/babelstore/payment/front/PaymentResponseAction.java; /home/cvs/dev/source/src/com/babelstore/payment/front/PaymentResponseAction.java,v <-- PaymentResponseAction.java new revision: 1.14; previous revision: 1.13 done Checking in src/com/babelstore/payment/front/PaymentResponseCancelAction.java; /home/cvs/dev/source/src/com/babelstore/payment/front/PaymentResponseCancelAction.java,v <-- PaymentResponseCancelAction.java new revision: 1.8; previous revision: 1.7 done Checking in src/com/babelstore/purchase/business/PurchaseBusiness.java; /home/cvs/dev/source/src/com/babelstore/purchase/business/PurchaseBusiness.java,v <-- PurchaseBusiness.java new revision: 1.166; previous revision: 1.165 done Checking in src/com/babelstore/purchase/business/PurchaseBusinessBean.java; /home/cvs/dev/source/src/com/babelstore/purchase/business/PurchaseBusinessBean.java,v <-- PurchaseBusinessBean.java new revision: 1.392; previous revision: 1.391 done Checking in src/com/babelstore/purchase/front/CheckoutPay1EuroCom.jsp; /home/cvs/dev/source/src/com/babelstore/purchase/front/CheckoutPay1EuroCom.jsp,v <-- CheckoutPay1EuroCom.jsp new revision: 1.12; previous revision: 1.11 done |
| Commentaire de Renaud Dierickx [ 19/juin/06 17:22 ] |
| On peut tester les evts sauf celui "départ vers 1euro" qui n'est pas développé... VOIR APP-10624 !! |
| Commentaire de Renaud Dierickx [ 19/juin/06 18:17 ] |
| En attendant de résoudre totalement le bug APP-10624, nous avons loggé un evt sur la selection d'1euro.com c'est à dire sur le passage à l'écran "Paiement sécurisé avec 1euro.com" |
| Commentaire de Cyrille Sarti [ 29/juin/06 15:05 ] |
|
Bonjour, Pour les évènements 270 et 340, serait-il possible d'avoir le montant de la transaction dans le champ "description" ? Merci d'avance et bon après midi, Annabelle. |
| Commentaire de Martin Iacampo [ 03/juil./06 13:14 ] |
|
Pourriez-vous répondre à la demande du BI avant activation en live ? Comme ça, les événements seront terminé dès le début ... :-) |
| Commentaire de Arnaud Forgues [ 03/juil./06 18:07 ] |
| Renaud ajoute le montant pour l'evenement 340. L'evenement 270 sera traité ultérieurement (un autre JIRA a été ouvert par RED) |
| Commentaire de Renaud Dierickx [ 03/juil./06 18:27 ] |
| Le dev est fait : Judd doit integrer cette modification dans la V901. |
| Commentaire de Patrick Condevaux [ 04/juil./06 17:05 ] |
|
les evenements ont bien l'air d'etre genere toutefois il reste des problemes signales dans le jira |
Installation Business Objects Production
(BIN-15)
|
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Production |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | François Le Lay | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | 0 minutes | ||
| Temps consacré: | 30 minutes | ||
| Estimation originale: | 30 minutes | ||
| Description |
|
Décommenter le Connector Coyote/JK dans le fichier
server.xml de tomcat, passer le port d'ecoute JK à 8010 au lieu de 8009
pour éviter d'interférer avec JBOSS
|
| Commentaires |
| Commentaire de François Le Lay [ 08/déc./05 11:45 ] |
|
Ranto au niveau de la création du worker bi je propose 8010 comme port :) |
| Commentaire de François Le Lay [ 14/déc./05 18:20 ] |
|
BO tourne sur tellus! Configuré avec les ports suivants: HTTP => 7070 JSP => 7043 Shutdown hook => 7010 AJP1.3 => 8010 (pour mod_jk) Un test a été fait depuis phaeton avec un browser texte sur le port 7070, on obtient bien la page pour se loguer dans l'InfoView. |
Installation serveur base de données
(BIN-6)
|
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Bug & Improvement |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Sous-tâche | Priorité: | Bloquant |
| Rapporteur: | Agathe Remy | Attribution: | Patrick Pereira |
| Résolution: | Corrigé | ||
| Estimation restante: | 1 heure, 30 minutes | ||
| Temps consacré: | 1 jour, 6 heures, 30 minutes | ||
| Estimation originale: | 2 jours | ||
| Commentaires |
| Commentaire de Agathe Remy [ 14/févr./06 19:18 ] |
|
Bonjour, Nous sommes bloqués aujourd'hui par des problèmes de temps d'exécution des mappings d'alimentation journalière du DataMart. Cela empèche la finalisation de la mise en production BI !!! J'aurais donc besoin d'une ressource DBA afin de m'aider à résoudre ce problème. Merci:-) Agathe |
| Commentaire de Sébastien Tournay [ 15/févr./06 09:14 ] |
| On va mettre Patrick sur le sujet pour te permettre d'avancer dans la mesure ou Edouard gére le déploiement de la V811. |
| Commentaire de Patrick Pereira [ 16/févr./06 18:13 ] |
|
Listes des actions menées : - augmentation de la taille des redolog 100 -> 500 Mo => moins de contention au moment des pointes de charges - alter table et index des tables ODS.ADVERT, DTM.TD_PRODUCT, STM.TF_ADVERT, parallème => on parvient à utiliser plus d'une CPU - augmentation du nombre de DB_WRITER + parallèlisation des insert => on utilise au maximum les disques. - diminution du paramètre db_file_multiblock_read_count de 16 à 8 pour diminuer l'utilisation systematique des full table scan. En plus, Agathe à fortement optimisé la requête. Conclusion, ça va beaucoup mieux, mais il faut continuer à chercher ! |
| Commentaire de Patrick Pereira [ 23/mars/06 18:46 ] |
| C'est bon maintenant. |
[APP-14297] isoler FAST et oracle : j'ai toujours l'impression que les pages FAST squatent les connexions du pool oracle Création: 15/déc./06 21:18 Mise à jour: 25/juin/07 18:48 Résolue: 25/janv./07 10:16 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Recherche produit |
| Affecte la/les version(s): | 11.0.0 (Merge et Maintenance) |
| Version(s) corrigée(s): | 12.0.0 |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Justin Ziegler | Attribution: | Olivier Bourgeois |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Classif1: | FAST |
| Projets PM archivés: | Maintenance 12.0.0 |
| Description |
|
il me semble important pour la stabilité globale de l'appli de se débarasser de ce probleme. Actuellement un pb de perf FAST degénère en pb de noManagedCon et plante donc complètement tous les utilisateurs sur toutes les pages !!! Cela s'est encore produit ce soir ! |
| Commentaires |
| Commentaire de Nicolas Chauveau [ 20/déc./06 10:00 ] |
| C'est le pb que je t'ai signalé hier en reunion. |
| Commentaire de Quentin de Chivré [ 27/déc./06 14:16 ] |
|
Analyser plus en détail : effectivement sur les pages
faisant appel a FAST, on ne devrait quasiment plus jamais avoir besoin
d'accéder à Oracle. Ce pb avait été identifié il y a qq temps et nous avait permis de voir que chaque page faisait un appel a Oracle pour calculer le nb d'article en panier => Andreï avait changé la façon d'afficher le panier dans le header. Visiblement le pb est revenu par un autre biais... Infoglue ? |
| Commentaire de Swan Desportes [ 27/déc./06 15:05 ] |
| A traiter en priorité au titre de la "RESERVE". |
| Commentaire de Olivier Bourgeois [ 04/janv./07 15:11 ] |
|
J'ai bien fini par identifier quelques requêtes Infoglue sur
SearchMono et AlphaNavigation : elles provenaient d'une mauvaise
utilisation de quelques Phrase dans deux JSPs. Désormais elles feront appel aux données qui sont en cache : c'est déjà ça de moins en requêtes. En ce qui concerne le calcul du panier, c'est un trade-off entre deux choses : la validité de l'affichage et le nombre de requêtes générées. Andreï avait supprimé la requête systèmatique en ne faisant une requête qu'après un paiement ou une mise à jour de panier (retrait par ex), cependant dans le cas d'une expiration de panier (par batch donc) les données affichées deviennent invalides : Renaud est donc revenu à la méthode initiale lors d'une modification récente. Reste un autre point suspect : il y a des requêtes de finder par PK sur USER_ACCOUNT autant de fois qu'il y a d'articles en panier ! FAST me semble innocent dans tout ça. |
| Commentaire de Quentin de Chivré [ 04/janv./07 19:44 ] |
|
1/ Mauvais usage de Phrase : ca veut dire que le cas peut se produire dans d'autres JSP ? Y a t'il un moyen de détecter cela de facon plus générale ? 2/ Panier dans le header: Pas d'accord avec la modif de Renaud alors... revenir a ce que faisait Andrei ! Quel est le n° de jira corrigé par Renaud ? 3/ Requetes sur user_account : Pas terrible, a corriger... 4/ FAST : FAST n'est pas vraiment "innocent" : si FAST ne répond pas, l'utilisateur reclique et reclique a nouveau et accapare des connexions Oracle => famine de connexions pour les autres des que 20 connexions sont bloquées ! solutions : - éviter que FAST ne réponde pas - et éviter que les pages utilisant FAST n'utilisent aussi Oracle |
| Commentaire de Olivier Bourgeois [ 05/janv./07 12:19 ] |
|
1/ Pour ça j'ai plutôt modifié PhraseFormat.format : le
problème vient de la migration des JSPs après l'unification de Phrase et
Label. Ces JSPs utilisent le nom complet de la JSP comme clé de Lexicon
plutôt que le nom formatté. 2/ Ok je vais voir ça avec Arnaud alors. Sinon est-ce qu'on ne pourrait pas mettre le nombre d'articles en session ? Il faut tout de même faire attention aux regressions car pour l'instant la collection d'articles est une variable publique de HeaderModel ! 3/ Corrigé : il y avait un booléen pour ne pas requêter les informations chronopost mais il ne servait à rien. Avec ce correctif on passe de 3 + nbArticles requêtes à 2 requêtes : une pour la Dynamo et une pour le panier. C'est déjà moins lourd 4/ Vu avec Martin ça paraît plus un problème de dimensionnement et de tuning des serveurs FAST en ce qui concerne le fait que FAST ne réponde pas. |
| Commentaire de Olivier Bourgeois [ 22/janv./07 17:28 ] |
|
2/ c'est |
| Commentaire de Olivier Bourgeois [ 22/janv./07 18:23 ] |
|
Ok je viens de comprendre le truc : le nombre d'article est
bien en cookie dans une variable cart, mais le modèle récupère néanmoins
le nombre d'articles depuis la base. Ensuite la jsp du header met à
jour la variable du cookie avec la valeur calculée dans le modèle. L'"optimisation" d'avant ne mettait pas à jour le cookie tout le temps, mais le modèle continuait de requêter la base tout de même. Alors je pense que l'idée à la base c'était de juste incrémenter décrémenter une variable dans le cookie ? |
| Commentaire de Olivier Bourgeois [ 25/janv./07 10:16 ] |
|
Je ferme ce Jira et j'en créée un nouveau pour implémenter
une nouvelle optimisation du mode de calcul des articles en panier : |
[APP-14279] perf fiche produit : dégradation lente depuis juin 2006 Création: 15/déc./06 10:00 Mise à jour: 09/mai/08 09:33 Résolue: 24/avr./08 11:04 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Perf |
| Affecte la/les version(s): | 11.0.0 (Merge et Maintenance) |
| Version(s) corrigée(s): | 21.0.0 |
| Type: | Bogue | Priorité: | Critique |
| Rapporteur: | Justin Ziegler | Attribution: | Manuel Sadok |
| Résolution: | Corrigé | ||
| Σ Estimation restante: | Non spécifié | Estimation restante: | Non spécifié |
| Σ Temps consacré: | Non spécifié | Temps consacré: | Non spécifié |
| Σ Estimation originale: | Non spécifié | Estimation originale: | Non spécifié |
| Pièces jointes: |
screenshot-1.jpg
screenshot-2.jpg
|
|||||||||||||||
| Liens des demandes: |
|
|||||||||||||||
| Sous-tâches: |
|
|||||||||||||||
| Pays: |
FRA - France
|
|||||||||||||||
| Site: | Prod | |||||||||||||||
| Projets PM: | Performances | |||||||||||||||
| Classif1: | TECH | |||||||||||||||
| Description |
|
Visible sur la courbe http://intra.priceminister.com/stats/mrtg/phaeton/requestcatprod.html => regarder l'annee entiere ! |
| Commentaires |
| Commentaire de Justin Ziegler [ 18/déc./06 14:53 ] |
|
Je constate de plus que nos serveurs historiques supportent de moins en moins bien la monté en charge. Ainsi, sur tellus (4 CPU xeon hyperthreadé à 1,4 GHz) on a du mal à dépasser les 100 utilisateurs simultané sans que la FP prenne 2s en temps de génération. De plus, cela semble fluctuer fortement... On observe ce même phénomène de fluctuation sur nos serveurs plus récents bi-pro hyper thread / 64 bit ! La FP serait elle devenue particulièrement complexe / couteuse ? NB : je n'ai pas l'impression que cela vienne de la base, meme si j'ai l'impression que la requete de selection des annonces pour une FP donnée pourrait être plus efficace que ce qu'elle est aujourd'hui. J'ai posté un autre jira ces derniers concernant la perf de la FP dans le cas ou il y a de nombreuses annonces... |
| Commentaire de Quentin de Chivré [ 27/déc./06 14:13 ] |
|
Pour le pb des FP avec trop d'annonces, il faut 1/ limiter le nb d'annonces retournées au nb d'annoncs affichées 2/ ajouter une requete de comptage des annonces associées a la FP (s'assurer qu'on a le bon index) On ajoute une requete pour générer la page mais si elle est bien optimisée, pas de pb. D'autre part, analyser la génération de cette page en détail : - activer les logs de mesure des temps d'execution (TimeLogger ?) - nb de requetes - plans d'executions - ... |
| Commentaire de Nicolas Chauveau [ 25/janv./07 15:30 ] |
| Doublon ? |
| Commentaire de Manuel Sadok [ 31/janv./07 12:16 ] |
|
Effectivement, les FP qui ont beaucoup d'annonces peuvent, à
l'heure actuelle, induire un problème de performance étant donné la
manière dont est exécutée puis traitée la requête. Cependant, les FP
ayant 600 annonces ne sont pas les plus nombreuses sur le site et ne
peuvent expliquer à elles seules le problème de perf rencontré. En regardant de plus près les modifications apportées à la FP sur la période durant laquelle les problèmes de performance ont commencé à être importants, on peut remarquer l'ajout du bloc Pangora et d'importantes modifications du CDF. 1/ En m'intéressant à Pangora et à ses implications sur l'application (hors communications AJAX), il apparait qu'il fait du travail inutile en doublon. D'un point de vue plus technique, au niveau du BaseProductModel : 1-a/ Le ProductDetail (avec attributs) est re-calculé (d'où requêtes BDD) alors qu'il existe déjà au sein de la même instance du model. 1-b/ Il y a un matcher sur l'arbre d'ancienne navigation pour retrouver le chemin de navigation du produit. Or c'est ce que fait précisément le BreadCrumbsModel déjà chargé. Il y aurait clairement une mutualisation intéressante à faire à ce niveau là, d'autant plus qu'à l'heure actuelle Pangora utilise uniquement l'ancienne navigation et non la nav par filtre, qui, à terme, sera la seule à être mise à jour. 2/ Le point précédent permet d'aborder une autre cause possible des dégradations de performance : le CDF. Dans ce cadre, il est intéressant de regarder le BreadCrumbsModel : 2-1/ Pour retrouver le CDF, il y a tout d'abord un matcher qui va chercher dans l'arbre de nav par filtre. Si le matching précédent ne ramène aucun résultat, un nouveau matcher est créé pour aller chercher, cette fois-ci, dans l'arbre d'ancienne navigation. Pour chacun de ces matcher, il y a un ProductDetail (avec attributs) de créer. Il pourrait déjà être intéressant de ne le calculer qu'une seule fois ! De plus, la nav par filtre n'en étant encore qu'à ces débuts, dans la quasi-totalité des cas on effectue donc ce double matching. 2-2/ La génération du tag XITI utilise désormais exactement la même logique que le CDF. Autrement dit, on double l'exécution de ce qui a été détaillé précédemment à chaque affichage de la FP. Il serait pertinent de ne faire tout le travail de matching de navigation une seule fois pour la génération du CDF et de XITI. 2-3/ De la même manière, le résultat de cette centralisation pourrait être utilisé par Pangora et donc alléger le traitement fait dans le BaseProductModel. De plus les données sont plus cohérentes que celles utilisées à l'heure actuelle. 3/ Au vu des 2 points précédents, un rapide calcul nous montre que lors d'un affichage d'une FP, on construit déjà 6 fois le même ProductDetail ! Outre une amélioration potentielle en mutualisant les traitements actuels, il est intéressant de se pencher sur la construction du ProductDetail. Le constructeur de ce dernier prend un Productnfo en paramètre. Or, ce ProductInfo n'est pas récupéré à partir d'un finder, mais à partir d'une requête applicative. La requête utilisée (ProductInfoSearchQuery) est également utilisée pour la recherche d'un produit en BO. Une jointure est faite entre product et user_account afin de ramener un ProductSubmitterInfo, qui contient en plus des données produits des informations sur le soumetteur de la fiche. Or, en FO, ces données sur le soumetteur ne sont pas utiles, d'autant plus qu'un cast en ProductInfo (au moment de la construction du ProductDetail) ne permet pas de les conserver. Un finder serait donc bien plus performant pour l'utilisation FO. Il pourrait déjà être intéressant d'effectuer ces optimisations afin de voir l'impact sur les perf de la FP. |
| Commentaire de Quentin de Chivré [ 31/janv./07 13:13 ] |
|
Je suis partant ! En ce qui concerne le BreadCrumbsModel, j'avais jeté un oup d'oeil il y a qq temps et avait été assez horrifié.... Bcp trop de calculs faits dedans et de connaissance du reste de l'application est centralisé la. Ce model devrait construire un chemin avec des "placeholders" alimentés selon le contexte => la même remarque que j'ai pu faire sur le TemplateModel qui dans le cadre des blocs promo a bcp trop de connaissance de son contexte d'execution. Il faut inverser la logique... => ainsi, quand on est dans le contexte d'une FP ou d'une nav, c'est le model associé qui doit charger les données et feeder le NreadCrumbsModel avec un sous-chemin servant a compléter le chemin de base Suis-je clair ? Je pense que ce truc a été codé a l'arrache par Andrei et mérite une re-conception ! |
| Commentaire de Manuel Sadok [ 01/févr./07 16:14 ] |
| Un quick-fix permettant de limiter certains traitements inutiles est fixé pour la V13.0.0 (1ère sous-tache) avant une refonte plus globale du mécanisme de génération du CDF fixée, pour le moment, pour la V14.0.0 (2ème sous-tache). |
| Commentaire de Manuel Sadok [ 10/mai/07 10:17 ] |
| En regardant la même courbe a l'heure actuelle, le quick-fix qui a été déployé fin février semble avoir été efficace. |
| Commentaire de Justin Ziegler [ 10/mai/07 11:37 ] |
|
Oui, sur cette courbe, on observe une amelioration à cette
date là, mais difficile d'être certain que c'est grace a ton fix. On peut aussi regarder les courbes coté SA : http://intra.priceminister.com/jbossofferbuy.html http://intra.priceminister.com/stats/mrtg/salus/offerbuymaxresponsetime.html (salus est representatif) http://intra.priceminister.com/stats/mrtg/sol/offerbuymaxresponsetime.html (sol également) http://intra.priceminister.com/stats/mrtg/terra/offerbuymaxresponsetime.html (terra aussi) |
| Commentaire de Justin Ziegler [ 10/mai/07 11:47 ] |
|
la différence entre les courbes SA et la courbe initiale vue du serveur web est la suivante : 1/ sur le serveur web : on effectue une requete sur une fiche produit précise, toujours la meme et on mesure le temps de reponse. 2/ sur les SA, on regarde les n dernieres lignes de log, et on graphe le max du temps de generation des fiches produit en regardant moi meme les log applicatif, j'ai constaté que seules certaines FP étaient très mauvaises : celle avec bcp d'annonce. Il faudrait voir si c'est toujours le cas. J'avais fait un jira avec toute l'analyse à l'époque... |
| Commentaire de Manuel Sadok [ 24/avr./08 11:04 ] |
| Je ferme ce Jira qui n'a plus de raison d'être : la sous-tache qui lui est associée doit faire l'objet d'un autre Jira à part. |
[APP-7653] Impossible de récupérer une valeur d'attribut afin de l'utiliser dans les spécifications Création: 27/févr./06 16:56 Mise à jour: 25/juin/07 18:35 Résolue: 21/août/06 18:43 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Mise en vente |
| Affecte la/les version(s): | 8.1.1 |
| Version(s) corrigée(s): | 9.0.3 |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Yassine Mouhammadou | Attribution: | Judd OSullivan |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
fiche_tech.JPG
|
| Description |
|
Dans le formulaire de mise en vente, on renseigne des champs
de saisie libre (input), des menus déroulant (select), des cases à
cocher (checkbox) etc. Pour certains types de produits, on crée une fiche technique, à l'aide des spécifications (étendue), dans le format correspondant. Les infos saisies dans un input sont bien récupérés et sont bien affichées dans la fiche technique ; par contre, quand il s'agit des checkbox ou des select, ce n'est pas la valeur choisies qui s'affichent mais l'id correspond. Voir l'imp. écran. Merci |
| Commentaires |
| Commentaire de Martin Sudmann [ 28/févr./06 13:45 ] |
| ce ne serait pas plutôt toi, les formulaires G3 ? |
| Commentaire de Yassine Mouhammadou [ 28/févr./06 14:08 ] |
|
Genevieve dit: je viens de travailler sur ce bug et j'ai vu que c'etait un pb de conf. En fait pour nous faire comprendre le problème, Yassine a changé la cellule de format de spec en question (format "Soumission Imprimantes" en Integ par ex). Pb constaté : Lorsque l'on crée une cellule "spécification" dans le format, on met dans l'alias le nom du paramètre du champ en question. Or, si le champ est un select (checkbox), on affiche l'id category au lieu de la valeur sélectionnée (cochée). Ce qui est fait actuellement pour contourner le pb : Par le biais d'une fonction en Javascript, on stocke dans un champ hidden le label correspondant à l'id de la valeur sélectionnée Et on fait appel à ce dernier dans le format pour les spécifications. Ce que l'on souhaiterait : Eviter de passer par un champ intermédiaire, car cela devient lourd à gérer et difficile à mettre en place en 3G Light. |
| Commentaire de Yassine Mouhammadou [ 28/févr./06 14:14 ] |
|
Voici un exemple du controunement fait dans les formulaires en question : <tr> <td>Format maximal</td> <td><select $form.select("imprimante_format", $form.value("imprimante_format")) style="width:80%" id = "$form.getControlName("imprimante_format")" onChange = "javascript:sel(document.getElementById('$form.getControlName("imprimante_format")').name, document.getElementById('$form.getControlName("imprimante_format_hide")').name);"> $form.options("imprimante_format", $form.value("imprimante_format")) </select> <input $form.input("imprimante_format_hide", $form.value("imprimante_format_hide")) type="hidden" id = "$form.getControlName("imprimante_format_hide")"> </td> </tr> <script> sel(document.getElementById('$form.getControlName("imprimante_format")').name, document.getElementById('$form.getControlName("imprimante_format_hide")').name); </script> ------------------------------------------------------------------------------------- function sel (chselect, chhidden) { document.frmSubmit.elements [chhidden].value = document.frmSubmit.elements [chselect].options [document.frmSubmit.elements [chselect].selectedIndex].text; } |
| Commentaire de Quentin de Chivré [ 27/juil./06 20:22 ] |
|
A chiffrer suite a tout ca : De : Quentin de Chivré [mailto:quentin.dechivre@priceminister.com] Envoyé : mercredi 26 juillet 2006 18:11 À : 'judd.osullivan@priceminister.com' Cc : 'mostafa diane' Objet : TR: Besoin d'aide pour avancer sur le site Espagne. Importance : Haute Il faudrait enqueter la dessus et chiffrer rapidemment une solution : http://pricejira.lan/browse/APP-7653 - a priori côté import il suffit, quand une cellule est mappée sur une spec, d'utiliser le label de la catégorie pour remplir la spec (plutot que les attributs qui lui sont attachés) Ca parait cohérent ? - côté formulaire pour reselectionner en cas d'erreur la bonne valeur, la je ne sais pas... Judd, tu peux me répondre la dessus ? Yassine peux t'expliquer le probleme plus en détail si besoin. Merci Q. -------------------------------------------------------------------------------- De : Jérôme VIVIES [mailto:jerome.vivies@priceminister.com] Envoyé : mardi 25 juillet 2006 16:59 À : quentin.dechivre@priceminister.com Cc : 'Ariane Baldinger' Objet : Besoin d'aide pour avancer sur le site Espagne. Importance : Haute Quentin, Nous sommes en train de passer beaucoup plus de temps que prévu sur le paramétrage de la mise en vente de certains produit CNet, du fait que nous devons manipuler beaucoup d'attributs, et surtout toutes les spécifications qui vont avec. La gestion des spécification implique des "bidouilles" très consommatrices de temps. En bref, ce jira devient très prioritaire à nos yeux : http://pricejira.lan/browse/APP-7653 Est-il très coûteux à réaliser, et serait-il possible de le faire réaliser rapidement ? Si non, saurais-tu nous suggérer d'autres solutions (par exemple : ne plus remplir les spécifications parce qu'elles seront abandonnées lors de la refonte de la base produit ?) Dis-nous ce que tu en penses. -- J. ________________________ J é r ô m e V I V I E S http://www.priceminister.com |
| Commentaire de Judd OSullivan [ 04/août/06 19:00 ] |
|
Le problème est que la valeur renvoyé par le formulaire
n'est pas le texte selectionné mais le category_id de noeud dans l'arbre
soumission. La solution la plus bête est de remplacer les category_ids
dans les 'option value' de dropdown avec la valeur texte. Mais si on
fait ca on casse le type advert_cell "mapping via reference de
categorie" (CATEGORY_REF_MAPPING). Ma solution est de préciser dans la cellule que la valeur est un category_id et n'est pas de texte pur. Donc dans un mapping, soit on ajout une 'Destination : Specification via categorie reference", soit on ajout un checkbox qui precise que la vrai valeur se trouve dans l'arbre de categorie. J'en parlerai avec l'équipe param lundi pour valider ca. C'est un demi-journée de dev. |
| Commentaire de Quentin de Chivré [ 07/août/06 10:03 ] |
|
Ca n'est pas forcément pour les specs, on peut l'utiliser
pour autre chose (en fait n'importe quel type de mapping existant) Le CATEGORY_REF_MAPPING est tres spécifique car il prend le contenu de la catégorie trouvée et le mappe sur "le produit" (pas une colonne ou un attribut donné) La il s'agit d'une source de données pouvant être mappée sur n'importe (?) quelle destination existante. J'ai l'impression que c'est plus un mécanisme de formulaire qu'un mécanisme d'import. En fait, si on crée un mécanisme type mapping, il faut se demander a quoi il sert dans un contexte import pur, sans formulaire. |
| Commentaire de Judd OSullivan [ 07/août/06 10:57 ] |
|
Déjà le CATEGORY_REF_MAPPING n'a pas de sens dans un
contexte import pur. En plus le problème est unique à la création des
specs selon l'équipe param. Je vois difficilement comment on peut changer le mécanisme de formulaire pour corriger ce problème. C'est comme j'ai expliqué dans ma commentaire de 4 août, on utilise les données de dropdown dans 2 cellule : une qu'a besoin un category_id, l'autre qui a besoin d'un bout de texte. Ce que je propose est comme ce que tu as proposé au début : "il suffit, quand une cellule est mappée sur une spec, d'utiliser le label de la catégorie pour remplir la spec" Donc moi je propose d'indiquer dans la cellule que la valeur données n'est pas de texte mais c'est un category_id ou on peut trouver le texte. |
| Commentaire de Judd OSullivan [ 10/août/06 18:41 ] |
|
Solution validé avec Jerome : 1/ Pour répondre à la besoin immediate : Creation de la destination 'Specification via reference de categorie' qui prend un category_id est qui met la valeur de le label de category dans la specification. 2/ Pour répondre aux futures besoins : Creation de la destination 'Variable via reference de categorie' qui prend un category_id est qui met la valuer de la libellé du category dans la variable préciser. |
| Commentaire de Judd OSullivan [ 21/août/06 18:43 ] |
| Dev est fait. |
| Commentaire de Fabien Farache [ 06/sept./06 14:59 ] |
|
ok... vu avec YAM (en integ) |
[DEC-429] transformation des PMV crédités non activés Création: 31/août/06 15:46 Mise à jour: 14/sept./07 14:55 Résolue: 26/sept./06 12:45 |
|
| Etat: | Fermé |
| Projet: | Reporting |
| Composants: | Marketing |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Critique |
| Rapporteur: | Alexandra Viravaud | Attribution: | Agathe Remy |
| Résolution: | Corrigé | ||
| Estimation restante: | 2 heures | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | 2 heures | ||
| Pièces jointes: |
pmv_activation_2006-09-25.xls
|
| Pays: |
FRA - France
|
| Description |
|
Salut, nous avons fait partir en mai dernier un mail sur toutes les personnes qui détiennent un PMV crédité non activé (9665 membres). Nous souhaiterions savoir, parmi les personnnes qui ont recu ce mail combien ont au jour d'aujourd'hui un PMV crédité activé. Théoriquement, la requête est prête : http://pricejira.lan/browse/DEC-307 ll suffit d'ajouter le champ PMV crédité activé. Merci Alexandra |
| Commentaires |
| Commentaire de Agathe Remy [ 01/sept./06 19:42 ] |
|
A voir si ce n'est pas trop long... Merci:-) |
| Commentaire de François Le Lay [ 26/sept./06 12:45 ] |
|
Ci-joint l'extract des personnes contactées en Mai concernant leur PMV inactivé. 1607 sur les 9665 ont activé leur PMV. |
| Commentaire de Alexandra Viravaud [ 12/oct./06 11:47 ] |
|
Salut Mohammed, est-il possible de récupérer le nb de paniers, le CA, la com, le nb de nouveaux acheteurs et le nb d'acheteurs générés par le mail PMV crédités non activés (via BI par exemple) ? Merci. Alex |
[BIN-294] [Finance] : Validation rapports PMV (Wallet by user et Wallet operations by user) Création: 22/févr./07 13:39 Mise à jour: 14/sept./07 17:37 Résolue: 09/août/07 17:20 |
|
| Etat: | Fermé |
| Projet: | Business Intelligence |
| Composants: | Finance |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Philippe Favrot | Attribution: | Romain Czornomaz |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
0 - Wallet_operations_by_user (19 fev 07 YTD).xls
debit_achat_20060731.csv
debit_achat_20070424.csv
Wallet_by_user (requête au 21 fev).xls
|
| Pays: |
FRA - France
|
| Description |
|
Agathe, j'ai deux soucis avec ces rapports : 1 - réconciliation des mouvements entre Titan et BO le rapprochement des cumul journaliers des mouvements entre Titan et BO fait ressortir un écart de 293,58 ¿ pour la journée du 31 juillet 06 pour le type de mouvement "Debit_purchase" (voir fichier excel joint / onglet "wallet operations by type / cellules avec rouge). 2 - réconciliation entre le solde cumulé des PMV déterminé avec le rapport "wallet operation by user" et celui donné par le rapport "wallet by user". - requête en date du 21 février ==> solde des PMV selon "wallet_by_user" = 2 432 409,98 ¿ (voir fichier joint) - le total des mouvements au 20 février (y compris cette journée) selon "wallet operations by user" donne un solde de 2 408 505,86 ¿ soit un écart de l'ordre de 23 k¿ A ta dispositin pour en parler Philippe |
| Commentaires |
| Commentaire de Agathe Remy [ 27/avr./07 18:10 ] |
|
Philippe, Je viens d'investiguer sur le premier problème. En fait, il s'agit d'un bug applicatif qui a laissé des opérations en statut 'SUBMITTED' alors que l'évènement de finalisation ('COMPLETION') avait eu lieu. Et comme les grands esprits se rencontrent, ce bug vient d'être corrigé lors du déploiement de la V14 et devrait être pris en compte dans les rapports BI début mai. Cordialement, Agathe |
| Commentaire de Philippe Favrot [ 02/mai/07 14:41 ] |
|
Bonjour, en fait je ne suis pas sur de bien comprendre ; s'il s'agit d'un bug applicatif pourquoi les opérations en question seraient-elles traitées de manière différente entre BO et Titan ? Ce matin, j'ai travaillé sur les mois de février, mars et avril : il y a également des écarts entre BO et Titan pour les journées suivantes : - 20 février / crédit BO - autre crédit : Titan : 3 240,33 ¿ BO : 3 799,43 ¿ - 24 février / débit BO - remboursé à tort : Titan : 42 ¿ BO : 32 ¿ - 21 mars / débit BO - remboursé à tort : Titan : 173,93 ¿ BO : 183,93 ¿ - 24 avril / débit achat : Titan : 25 221,28 ¿ BO : 24548,21 ¿ Philippe |
| Commentaire de Philippe Favrot [ 02/mai/07 19:07 ] |
|
L'utilisation du rapport "wallet operations by user" permet de traiter les écarts des 20 / 24 février et du 21 mars. En revanche, celui du 24 subsiste ; tu peux regarder STP. Merci Philippe |
| Commentaire de Romain Czornomaz [ 10/juil./07 15:24 ] |
|
Philippe, Voici la picèe jointe comprenant les operations de "debit achat pour la journée du 31 Juillet 2006. Romain |
| Commentaire de Romain Czornomaz [ 10/juil./07 15:25 ] |
|
Philippe, Voici la picèe jointe comprenant les operations de "debit achat pour la journée du 24 Avril 2007. Romain |
[APP-26706] [META-TACHE] Modification des tracking sites-under + tracking e-mails questions Création: 02/oct./09 11:45 Mise à jour: 01/oct./10 16:12 Résolue: 29/sept./10 12:02 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 78.0.0 (CTN-TU) |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Fabrice Feugas | Attribution: | Dispatcher (Pôle CTN) |
| Résolution: | Corrigé | ||
| Σ Estimation restante: | Non spécifié | Estimation restante: | Non spécifié |
| Σ Temps consacré: | Non spécifié | Temps consacré: | Non spécifié |
| Σ Estimation originale: | Non spécifié | Estimation originale: | Non spécifié |
| Pièces jointes: |
SU_supp_t_40-20091002.pdf
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sous-tâches: |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Pays: |
FRA - France
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Projets PM: | *** RESERVE *** | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Projets PM archivés: | Tracking affiliation |
| Commentaires |
| Commentaire de Fabrice Feugas [ 06/oct./09 15:35 ] |
| Le planning en P.J |
| Commentaire de Ghislain Gridel [ 06/oct./09 15:46 ] |
| attention, il ne faut pas désactiver les t= de clubic comme indiqué dans le planning mais seulement le rapport automatique BI, sous condition que clubic accepte le nouveau modèle de rémunération; Mathieu vous tiendra au courant. |
| Commentaire de Ghislain Gridel [ 06/oct./09 15:47 ] |
| Par ailleurs, il n'existe pas de tag clubic. |
| Commentaire de Fabrice Feugas [ 06/oct./09 15:50 ] |
| ok c'est noté. |
| Commentaire de Fabrice Feugas [ 14/oct./09 15:34 ] |
| Présentation du projet dans cette page : http://pricewiki.lan/Wiki.jsp?page=Tracking%20afiliation%20%28Sites%20Under%20%2B%20emails%20question%29 |
| Commentaire de Ghislain Gridel [ 22/oct./09 16:06 ] |
|
Bonjour, clubic a accepté le changement de rémunération. Le contrat est en cours de rédaction. Peut-on modifier le rapport automatique svp ? PriceMinister : Partner - Weekly revenue by tracking group PriceMinister : Clubic - Appel à facture mensuel Il faut modifier : - le VA capturé en commission capturée - La rémunération de 8% du VA capturée à 57.5% de la commission capturée Le nombre de paniers ne change pas. Merci ! Ghisalin |
| Commentaire de Fabrice Feugas [ 22/oct./09 18:25 ] |
|
Ok Ghisalin ! Peux-tu (ou Mathilde) faire un sous-JIRA avec la demande bien précise de ce que vous souhaitez modifier dans le rapport, pour quelle date, et l'attribuer au B.I ? Merci. |
| Commentaire de Fabrice Feugas [ 22/oct./09 18:46 ] |
|
Les changements (nouveaux tags et désactivation des codes de
tracking) seront effectifs à partir du 01/11 si on intervient sur le BO
la veille. Le système basculera au redémarrage serveur. Merci. |
[MeV] Migration 4G Image & Son
(APP-30514)
|
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Mise en vente |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 78.1.0 |
| Type: | Sous-tâche | Priorité: | Majeur |
| Rapporteur: | Simon Stevant | Attribution: | Simon Stevant |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Projets PM: | MEV - Image et Son |
| Commentaires |
| Commentaire de Simon Stevant [ 29/juil./10 16:02 ] |
|
Passage du formulaire MeV 3G au formulaire 4G pour le type Amplificateurs. Formulaire effectué sur la plateforme DEV, les tests de soumissions ont été effectués, formulaire opérationnel en Dev =>Les détails de la migration sont renseignés sur le Wiki MeV 4G Univers image et son http://pricewiki.lan/Wiki.jsp?page=MeV%204G%20-%20Univers%20Image%20%26%20Son |
| Commentaire de Simon Stevant [ 29/juil./10 16:07 ] |
|
Tests de mise en vente effectués aujourd'hui, Les valeurs d'attributs associées à [ PMA0001000 Amplificateur / Type ] n'apparaissaient pas car elles étaient affectées d'une qualification Pierre. =>Le détail des modifications effectuées sur les qualifications est résumé dans le tableur joint à la méta-tâche. Le formulaire pour le type Amplificateurs est fonctionnel sur DEV 3 |
| Commentaire de Simon Stevant [ 24/août/10 13:49 ] |
|
Envoyé à recetter à la valid et aux commerciaux. Retours: - Valid: - Akai et marrantz sont en doublon dans la liste des fabricants - Il manque amplificateur classique dans type d'amplificateur. - Service commercial: RAS |
| Commentaire de Simon Stevant [ 24/août/10 13:53 ] |
|
@Valid: Il existait deux valeurs Marantz (PM00001235 et Z01928) mappées sur En-tête fabricant pour le type ampli, comme aucune des deux n'était portée par un produit, j'ai démappé PM00001235 Même réflexion pour Akai , j'ai démappé P50073 |
| Commentaire de Simon Stevant [ 24/août/10 13:55 ] |
| La valeur amplificateur classique n'existe pas, faut il la créer? |
| Commentaire de Nicolas Clais [ 03/sept./10 11:42 ] |
|
Titre exemple à ajouter : Pioneer VSX819HS - Amplificateur Home Cinéma - 5 x 130 Watts - Décodeurs Dolby True HD et DTS-HD - 3 Entrées HDMI - Argent Descriptif : - Puissance RMS : 5 x 130 W (1 kHz, 1% THD, 6 ohms) - Réponse en fréquence (ligne) : 5 Hz - 100 kHz (+0 / -3 dB) - Rapport signal-bruit (ligne) : 98 dB - Convertisseur N/A : 192 kHz / 24 bits - Convertisseur A/N : 96 kHz / 24 bits - Bi-Amplification possible |
| Commentaire de Simon Stevant [ 13/sept./10 11:42 ] |
|
Recette aujourd'hui et étude des valeurs d'attribut en prod:
En tête / fabricant _ Il faudra ajouter une valeur "Autre fabricant" _Doublon Akai _Doublon Marantz |
| Commentaire de Simon Stevant [ 05/oct./10 10:25 ] |
| Formulaire terminé |
[IMP-7154] probleme import chavetvc Création: 11/oct./10 10:06 Mise à jour: 11/oct./10 15:41 Résolue: 11/oct./10 15:41 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Demande commerciale |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Mineur |
| Rapporteur: | Anne Korchia | Attribution: | Jérome Marianne |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Login: | chavetvc |
| Séparateur: | Tabulation |
| Type de traitement: |
Mise à jour/création annonces (écrasement)
|
| Description |
|
mail pro
PSEUDO / CHAVETVC DEPUIS QUELQUES MOIS LORSQUE JE VOUS ENVOIE MON FICHIER IL N'EST PAS ECRASE. LES INVENDUS RESTENT ENCORE EN VENTE. LES NOUVEAUX SONT EN LIGNES PAR CONTRE. MERCI DE FAIRE LE NECESSAIRE. CORDIALEMENT. |
| Commentaires |
| Commentaire de Jérome Marianne [ 11/oct./10 15:41 ] |
|
Le mode Écrasement à été mis sur le profil import apparaissant en front.
Le profil FTP est lui déjà en Écrasement. Le prochain import via ce biais sera en Écrasement. |
[IMP-7202] net-treasure : explosion du stock Création: 18/oct./10 15:45 Mise à jour: 26/oct./10 09:46 Résolue: 26/oct./10 09:46 |
|
| Etat: | Résolu |
| Projet: | Paramétrage - Import |
| Composants: | Support monitoring |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Laurent Payot | Attribution: | Laurent Payot |
| Résolution: | Corrigé | ||
| Σ Estimation restante: | Non spécifié | Estimation restante: | Non spécifié |
| Σ Temps consacré: | Non spécifié | Temps consacré: | Non spécifié |
| Σ Estimation originale: | Non spécifié | Estimation originale: | Non spécifié |
| Sous-tâches: |
|
|||||||||||||||
| Pays: |
GBR - Royaume Uni
|
|||||||||||||||
| Login: | net-treasure (UK) | |||||||||||||||
| Séparateur: | N/A | |||||||||||||||
| Type de traitement: |
N/A
|
| Description |
|
Aujourd'hui on constate une explosion du stock sur FR et UK (pour ES le stock d'aujourd'hui n'apparaît pas encore).
Stock FR: 11/10/2010 366082509 12/10/2010 366354975 13/10/2010 369468701 14/10/2010 368461017 15/10/2010 367992410 16/10/2010 369353769 17/10/2010 370029843 18/10/2010 708833006 Stock UK: 11/10/2010 103135794 12/10/2010 105523082 13/10/2010 105186819 14/10/2010 104682678 15/10/2010 104970342 16/10/2010 105016707 17/10/2010 105196031 18/10/2010 451431350 |
| Commentaires |
| Commentaire de Laurent Payot [ 18/oct./10 15:52 ] |
| Mail d'information envoyé à param CC Agathe |
| Commentaire de Laurent Payot [ 18/oct./10 16:21 ] |
|
un premier suspect semble être net-treasure (UK) /
treasure-fr (FR) qui a importé le 17 octobre sur UK et FR 13 fichiers de
25 000 lignes et un fichier de 40 000 lignes, à chaque fois avec un
stock de 999 :
(13 x 25 000 + 40 000) * 999 = 364 635 000 ce qui correspond à l'augmentation |
| Commentaire de Laurent Payot [ 18/oct./10 16:52 ] |
| Jeremy, puis-je mettre toutes les annonces du pro avec un stock illimité? Ou alors à combien? (il met des quantités = 999) |
| Commentaire de Laurent Payot [ 18/oct./10 16:56 ] |
| Vu avec Jérémy par téléphone: ok pour quantités illimitées. |
| Commentaire de Laurent Payot [ 18/oct./10 17:09 ] |
| UK: donné droit quantités illimitées + modifié format + relancé 43 fichiers manuellement |
| Commentaire de Laurent Payot [ 18/oct./10 17:13 ] |
| FR: donné droit quantités illimitées + modifié format + relancé 37 fichiers manuellement |
| Commentaire de Laurent Payot [ 18/oct./10 17:19 ] |
| ES: donné droit quantités illimitées + modifié format + relancé 43 fichiers manuellement |
| Commentaire de Laurent Payot [ 19/oct./10 09:38 ] |
| Le stock du 18 a explosé avec des fichiers du 17. Il y a un jour de décalage par rapport a l'affichage du BO. Il faut attendre demain pour confirmer le retour à la normale. |
| Commentaire de Laurent Payot [ 20/oct./10 10:25 ] |
| Stock toujours au même niveau sur les trois sites. |
| Commentaire de Laurent Payot [ 20/oct./10 10:34 ] |
| pour tant net-treasure semble etre le seul suspect. Les quantités des annonces sont bien passées en illimité. Lorsque l'on passe la quantité en illimité est-ce que le stock BI est calculé a partir de la dernière quantité connue? Cela expliquerait la non modification du stock. Je vais faire le test sur (d'abord sur UK) en vidant le stock complètement puis en ressoumettant les fichiers depuis le dernier écrasement. |
| Commentaire de Laurent Payot [ 21/oct./10 10:40 ] |
| Le vidage de stock tombe sans arret en erreur et est inutilisable pour vider des stocks importants. Je vais essayer avec Daniel de récupérer la liste des ref annonces par webservices et faire un format pour les effacer. |
| Commentaire de Laurent Payot [ 22/oct./10 18:12 ] |
| après quelques péripéties (encodage, aplatissement etc) les stock sont en train d'etre vidés. Déja terminé sur UK. Il restera à relancer les fichiers ultérieurs au dernier écrasement. |
| Commentaire de Laurent Payot [ 25/oct./10 10:29 ] |
|
Les annonces ont bien été supprimées sur les 3 sites. Retour aux stocks normaux.
163 fichiers du pro relancés manuellement sur le UK. |
| Commentaire de Laurent Payot [ 25/oct./10 10:57 ] |
| 126 fichiers relancés manuellement sur FR. |
| Commentaire de Laurent Payot [ 25/oct./10 11:36 ] |
| 162 fichiers relancés manuellement sur ES. |
| Commentaire de Laurent Payot [ 26/oct./10 09:46 ] |
| Les fichiers ont bien été traités sur les trois sites. Quantité bien fixée à illimité. |
OP de collecte 2010 - import de contacts
(CAT-3032)
|
|
| Etat: | Résolu |
| Projet: | Paramétrage - Non Import |
| Composants: | Import de contacts Marketing |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Sub-bug | Priorité: | Bloquant |
| Rapporteur: | Carole Boucheny | Attribution: | Carole Boucheny |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Désabonnement aux newletters de tous les contacts.
|
| Commentaires |
| Commentaire de Carole Boucheny [ 28/oct./10 17:42 ] |
|
1/ ANALYSE DU PROBLEME
Jusqu'à présent le partenaire remplissait une colonne par Oui ou Non. Cette colonne était interprétée comme cela de notre côté : Si Oui --> Abonnement aux newletters Price et Partenaire Si Non --> Abonnement aux newletters Price La colonne Oui et Non actuelle correspond en fait à : Oui --> Abonnement aux newletters Price Non --> Aucun abonnement Nous avons donc abonnement : - de personnes à la NL PM, alors qu'elles n'auraient pas dû l'être. - de personnes à la NL PM + partenaires alors qu'elles auraient dû être abonnées seulement à la NL PM. De plus, nous avons en fait 3 cas d'abonnements possibles dans ce jeu : - Abonnement aux newletters Price - Abonnement aux newletters Price et Partenaire - Aucun abonnement 2/ SOLUTION Reprendre le script utiliser aux derniers problèmes avec le même cas. --> Patrick a lancé le script --> L'import pourra donc être relancé et réabonner les personnes comme il se doit |
| Commentaire de Carole Boucheny [ 28/oct./10 17:44 ] |
|
Voici la procédure qu'avait donné Agathe lors du dernier problème :
Bonjour, Nature du problème : Des comptes sont abonnés par erreur aux Newsletters AVAL et VMC (co-registration mise en place depuis le 30/11/2009) en raison d’un mauvais paramétrage : · Lors d’import de jeux concours · Lors de la création de coupons via WebService Action correctrice déjà mise en place : · Correction de la moulinette d’abonnement lors de la création des coupons via WebService (des comptes sont abonnés tous les jours de cette manière) livrée le 29/05/2010 Proposition de process pour la correction de l’historique : · Validation des critères d’identification des « comptes abonnés à tord » par Benoît TABAKA · Développement des scripts de correction par les dbas afin de : o Désabonner les comptes abonnés à tord o Créer les évènements associés avec une description du type « correction d’abonnement à tord via batch contact » · Validation des scripts par Arnaud pour vérifier qu’ils respectent les règles métiers du site · Passage des scripts en Production · Réinitialisation des bases emails chez VMC et AVAL afin de répercuter ces corrections (génération de fichiers full par l’équipe BI) Critères d’identification des « comptes abonnés à tord » : (à valider par Benoît) · Comptes PM inscrits ou prospects · Abonnés aux Newsletters AVAL et VMC · Ayant été abonnés via batch contact (import de jeu concours ou moulinette webservice coupon) · Dont la date d’abonnement par batch contact est inférieure à la date d’abonnement par inscription (si inscrit depuis) Vous trouverez ci-joint la requête associée (sur la base BI car pb d’évènements archivés sur la base OLTP). Je reste à votre disposition si vous avez des questions, Agathe |
| Commentaire de Carole Boucheny [ 28/oct./10 17:45 ] |
|
Requête qui avait été utilisée :
SELECT distinct ta_usr_subscription.user_account_id, = ta_usr_subscription.mail_subscription_id FROM ta_usr_subscription, (select user_account_id, mail_subscription_id, max(creation_date) = as creation_date from dwh.ta_usr_event where use_type_code=3D600 and description like '%Batch contact%' and MAIL_subscription_ID in (200,210)-- AVAL et VMC and creation_date>=3Dtrunc(to_date('20091130','YYYYMMDD')) and creation_date<TRUNC(SYSDATE) group by user_account_id, mail_subscription_id ) batch_contact_subscription, (select user_account_id, mail_subscription_id, max(creation_date) = as creation_date from dwh.ta_usr_event where use_type_code=3D600 and description not like '%Batch contact%' and MAIL_subscription_ID in (200,210)-- AVAL et VMC and creation_date>=3Dtrunc(to_date('20091130','YYYYMMDD')) and creation_date<TRUNC(SYSDATE) group by user_account_id, mail_subscription_id ) registration_subscription where = batch_contact_subscription.USER_ACCOUNT_ID=3Dta_usr_subscription.USER_ACC= OUNT_ID and = batch_contact_subscription.mail_subscription_id=3Dta_usr_subscription.mai= l_subscription_id and = batch_contact_subscription.USER_ACCOUNT_ID=3Dregistration_subscription.US= ER_ACCOUNT_ID(+) and = batch_contact_subscription.mail_subscription_id=3Dregistration_subscripti= on.mail_subscription_id(+) and = batch_contact_subscription.creation_date>nvl(registration_subscription.cr= eation_date,trunc(to_date('20091129','YYYYMMDD'))) and ta_usr_subscription.USS_STATUS_CODE=3D10 -- abonnement actif and ta_usr_subscription.MAIL_subscription_ID in (200,210)-- AVAL et VMC and ta_usr_subscription.creation_date<TRUNC(SYSDATE) and = ta_usr_subscription.change_date>=3Dtrunc(to_date('20091130','YYYYMMDD')); |
| Commentaire de Carole Boucheny [ 28/oct./10 17:53 ] |
|
Le script a été exécuté :
Bonjour. Le script de désabonnement vient d’être exécuté. Comme précédemment les abonnements qui ont être fait manuellement après la création du compte contact sont conservés. Pour les 215 534 autres, ils ont vu leur change_date modifiée à la date du jour et disposent d’un événement dont la description est « JIRA Pour plus d’info le script se trouve sur hercule à l’emplacement suivant : /data/priceminister/manualdeploy/V79_0_1/V79_FR_compte_abonnees_a_tord_JIRA- Patrick. Le 215 534 correspond aux nombres d'abonnements et non de contact. |
[APP-31808] Manque stat réclamations "Annulation" dans fiche-article Création: 16/nov./10 13:57 Mise à jour: 18/nov./10 14:58 Résolue: 18/nov./10 14:54 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Back-Office |
| Affecte la/les version(s): | 81.0.0 (TX-Q) |
| Version(s) corrigée(s): | 81.1.1 |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Habib-Sylvain Gourguet | Attribution: | Jeremy Maltis |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
TMP_manque_annul_FA.png
|
| Pays: |
ALL - Tous
|
| Projets PM: | CoSAV : Gestionnaire de commande |
| Description |
|
Voir screenshot.
Afin de mieux étudier le profil de chaque utilisateur (et notamment chaque vendeur), il faut ajouter la stat concernant le nombre de réclamations de type "Annulation vendeur" dans la ligne "Claims Achats/Ventes". Merci d'avance. |
| Commentaires |
| Commentaire de Habib-Sylvain Gourguet [ 16/nov./10 17:47 ] |
|
Thomas, tu penses que ce JIRA peut être traité en TX-Q ?
Merci d'avance. |
| Commentaire de Thomas Landru [ 16/nov./10 18:01 ] |
|
Il n'est pas prévu de CoSAV pour la TX-Q et nous avions
défini une solution ensemble pour que vous puissiez suivre ces chiffres
directement en BI (ce fut le sujet de nombreuses réunions entre nous)
donc on ne peut pas s'avancer pour le moment.
On a mis ca dans le fichier d'amélioration en priorité élevée. |
| Commentaire de Thomas Landru [ 17/nov./10 18:04 ] |
| Jeremy peux tu livrer ca sur le tronc pour la 81.1.1 ? |
| Commentaire de Jeremy Maltis [ 17/nov./10 18:17 ] |
| C'est good ! |
| Commentaire de Habib-Sylvain Gourguet [ 17/nov./10 18:24 ] |
|
Splendide !
Merci pour votre souplesse et votre célérité ! |
| Commentaire de Thomas Landru [ 17/nov./10 18:32 ] |
| Tu es donc invité à venir détacher les post-it demain matin :) |
| Commentaire de Arnaud Forgues [ 18/nov./10 11:35 ] |
| Je déplace ce jira en 81.1.1 (patch post 81.0.0) car déjà corrigé |
| Commentaire de Habib-Sylvain Gourguet [ 18/nov./10 14:44 ] |
|
Manque la stat côté Acheteur (comme indiqué dans le descriptif du JIRA).
Moins prioritaire que côté vendeur : vous préférez un nouveau JIRA pour la 81.1.1.1 ? |
| Commentaire de Jeremy Maltis [ 18/nov./10 14:54 ] |
|
D'accord.
je ferme ce JIRA, j'en ai ouvert un autre : |
[BIN-676] [Validation] : Dossiers image dans univers média Création: 20/mai/10 14:31 Mise à jour: 18/nov./10 18:07 |
|
| Etat: | Ouvert |
| Projet: | Business Intelligence |
| Composants: | BackOffice |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Xavier Fabregat | Attribution: | Julien Girardet |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Description |
|
Serait-il possible de créer dans l'univers média des trois
pays, des dossiers "Image" et "Image event" identique aux dossiers
"Gallery" et "Gallery event", donc avec Image id, Image event id,
etc... avec en plus une dimension permettant la différenciation entre
les images annonce et les images produit.
|
| Commentaires |
| Commentaire de Agathe Remy [ 20/mai/10 15:12 ] |
|
Bonjour, Stp, pourrais-tu nous donner un peu de contexte et l'objectif de ta demande? En effet, les infos que tu demandes n'existent pas... Agathe |
| Commentaire de Xavier Fabregat [ 20/mai/10 15:56 ] |
| Nous souhaiterions faire des rapports quotidiens concernant les images validées,refusées et supprimées par la validation afin de mieux appréhender et améliorer notre métier. Nous souhaiterions par la même occasion, différencier dans ces rapports les images annonce des images produit, ainsi que le nombre d'image utiliser par la validation pour enrichir une fiche produit. |
| Commentaire de Agathe Remy [ 07/juin/10 17:43 ] |
|
Bonjour Xavier, - Pour suivre quotidiennement les images validées, refusées et supprimées par la validation, il y a plusieurs moyens de le faire avec l'univers existant (notamment en se basant sur les évènements). - Pour différencier les images annonce des images produit, nous devons créer de nouvelles informations:-( Il faut prévoir un projet d'alimentation. Ce n'est donc pas faisable facilement. Mais je note le besoin pour essayer de l'adresser lors d'un projet. - Pour identifier les images utilisées par la validation pour enrichir une fiche produit, il y a certainement moyen d'ajouter facilement l'info dans l'univers. Mais pour cela, il me faudrait un exemple pour identifier la bonne donnée. Stp, peux-tu m'en fournir un? Merci, Agathe |
| Commentaire de Xavier Fabregat [ 17/juin/10 14:29 ] |
|
Bonjour, En ce qui concerne le suivi des images validées, j'ai un rapport intitulé "Validation images" dans le dossier "Aurelien-Xavier/Au secours" qui n'arrive pas à me convaincre.J'ai retourné l'univers média dans tous les sens, les chiffres obtenus me laisse toujours autant perplexe.Je serais pas contre un début de piste. Merci |
| Commentaire de Agathe Remy [ 17/juin/10 15:11 ] |
|
Bonjour Xavier, En fait, il me faudrait un exemple de fiche produit (Id) avec des images utilisées par la validation pour l'enrichir. Merci, Agathe |
| Commentaire de Aurélien Vergalli [ 21/juin/10 09:29 ] |
|
Bonjour, Exemple de FP enrichie: ID 439446, enrichie avec images annonce ID 180010471, le 21/06/2010 à 09:25 lors de leur validation. - images annonce: http://bo.priceminister.com/image_back?action=imageadvertview&advertid=180010471 - images FP (pas d'événement): http://bo.priceminister.com/image_back?action=imageview&productid=439446 |
| Commentaire de Agathe Remy [ 21/juin/10 11:49 ] |
|
Merci Aurélien. Nous allons donc ajouter la dimension "Gallery source label" dans la classe "Gallery" de l'univers MEDIA. Pour identifier les image utilisées par la validation pour enrichir une fiche produit, il faudra sélectionner les galeries ayant un "Gallery source label" ="PRICEMINISTER_BACK_OFFICE". Nous vous préviendrons lorsque cet ajout sera livré en Production. A votre dispo, Agathe |
| Commentaire de Agathe Remy [ 24/juin/10 16:29 ] |
|
Bonjour, Nous venons de livrer les évolutions de l'univers MEDIA en France, Spain et UK: - Déplacement des indicateurs dans les classes des dimensions associées pour faciliter leur utilisation (et suppression de la classe Indicators) - Ajout de la dimension "Gallery source label" dans la classe "Gallery" pour identifier les images utilisées par la validation pour enrichir une fiche produit Svp, pouvez-vous valider ces modifications? Je suis à votre dispo si vous avez des questions, Agathe |
| Commentaire de Xavier Fabregat [ 25/juin/10 11:56 ] |
|
Bonjour, Merci pour ces modifications, que je n'arrive toutefois pas encore à exploiter correctement.Je me demandais si une dimension "Gallery Change Label" dans la classe "Gallery Event" ne nous serait pas d'un plus grand secours.De même afin de contrôler et corroborer les rapports, nous aimerions avoir des dimensions "Image ID" et "Product ID" dans la classe "Gallery" qui nous sont familiers et vérifiables dans le BO contrairement à Gallery qui ne nous parle pas.Faut -il faire un autre Jira ou celui-ci peut-il servir de fil de discussion pour tout ce qui concerne l'univers MEDIA. Merci |
| Commentaire de Agathe Remy [ 25/juin/10 17:11 ] |
|
Bonjour Xavier, - Il me semble que l'information "Gallery Change Label" correspond à la dimension "Gallery event type label". Sinon, je ne vois pas à quoi tu fais allusion : stp, est-ce que tu pourrais me donner un exemple? - Pas de problème pour ajouter la dimension "Image Id" dans l'univers "Gallery". Nous vous préviendrons lorsque cet ajout sera livré en Production. - Pour la dimension "Product ID", nous ne récupérons pas aujourd'hui les informations relatives aux images produits dans le BI. Il faut prévoir un projet d'alimentation. Mais je note le besoin pour essayer de l'adresser lors d'un projet. Pas de pb pour continuer via ce JIRA:-) A ta dispo, Agathe |
| Commentaire de Xavier Fabregat [ 28/juin/10 14:44 ] |
|
Bonjour, Je crains que "gallery source label",ne donne, et c'est à priori le cas sur mes premiers rapports(cf. le rapport "Aurelien-Xavier/Au secours/validation images"), que la provenance de la soumission des images que nous validons.Alors que l'on souhaite comptabiliser les images déjà existantes ou pas sur la fiche quelque soit sa provenance front ou back, que nous considérons légitime pour être l'illustration de la fiche produit.Il me semble que c'est plus du domaine de l'événement, malheureusement toutes les images que nous validons non pas d'événement, donc pas traçable. Ma réflexion se basait en fait sur l'univers Product event, qui possède des dimensions "product source label" et "Product change label" possédant les mêmes valeurs que "gallery source label", et je pensais obtenir quelque chose de plus probant par ce biais.En fait je recherche la provenance de la validation. Merci |
[BIN-448] [First tracking] : amélioration du rapport Buyer distribution by purchase count and first tracking group Création: 23/mai/08 15:38 Mise à jour: 18/nov./10 18:07 |
|
| Etat: | Ouvert |
| Projet: | Business Intelligence |
| Composants: | Marketing Acquisition |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Mineur |
| Rapporteur: | Thomas Beylot | Attribution: | Julien Girardet |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Liens des demandes: |
|
||||||||
| Pays: |
FRA - France
|
||||||||
| Description |
|
Hello sur ce rapport (que je viens de regarder) je pense qu'on pourrait l'améliorer. En lui ajoutant le nombre de contact concernés par chaque first tracking (car aujourd'hui nous n'avons que les volumes d'acheteurs sans aucune idée de taux de transfo, indicateur clé de qualité). Je sais qu'on peut les avoir facilement à côté mais ce serait plus simple non ? Et en ayant la répartition des comptes acheteurs dans le temps, pour savoir à partir de quand un tracking group est rentable (car sinon il nous faut sortir le fichier sur certaines périodes pour trouver le point exact de rentabilité dans le temps). A votre dispo pour en parler. Thomas. |
| Commentaires |
| Commentaire de Agathe Remy [ 26/mai/08 10:59 ] |
|
Bonjour Thomas, J'ai l'impression que ce que tu demandes reviendrait à migrer le rapport http://intra.priceminister.com/stats/reports/confid/Suivi_Acheteurs/suivi_acheteurs_2008-05-25.txt.gz dans BI en ajoutant la notion de first tracking. En effet, la rapport "Buyer distribution by purchase count and first tracking group" a pour objectif de donner une image de la répartition des acheteurs par nombre de paniers effectués pour un dispositif de provenance donné (first tracking). Pour étudier le taux de transfo et la répartition des comptes acheteurs dans le temps, il ne s'agit plus d'une image, mais d'un suivi de l'activité. D'ailleurs il existe un autre rapport dans le répertoire First tracking qui te permet de suivre le taux de transfo : "User transformation by first tracking". A ta dispo pour en discuter. Agathe |
| Commentaire de Thomas Beylot [ 22/sept./08 15:14 ] |
|
hello mille ans après voici donc mon nouveau commentaire sur ce jira. pour rappel ces rapports avaient été demandé dans le cadre suivant : - depuis 2005 on travaille avec des agences pour monter des Op de recrutement de clients (les fameux "jeux-concours"). en plus d'un forfait fixe payé à l'agence, nous leur reversons un variable pour chaque email nouveau recruté. - suite à la fin du jeu, on importe les contacts dans la base et on essaye d'en faire des clients. => du coup, l'idée serait de : - calculer la valeur client d'une OP jeux concours. - savoir au bout de combien de temps cette valeur client dépasse le coût unitaire du nouvel email recruté. d'où ma demande d'avoir sur un first tracking donné: - le nombre de contacts au total - et un suivi au mois le mois car vu que je n'ai qu'un total sur la période il faudrait que sorte le rapport chaque mois et ça prend du temps :) j'ai donc jeté un oeil au rapport de suivi acheteur et donc le top effectivement serait de pouvoir avoir ceci avec la possibilité de trier par groupe de tracking et d'avoir le nb de contacts. Mais je pense qu'un rapport plus simple peut aussi le faire : on filtre sur le groupe de tracking t=x, et sur la période qu'on détermine (de juin 2006 à octobre 2008) on a sur chaque mois le volume d'affaire, comm, nb de paniers etc. comme ça je pourrais voir à quel mois le budget dépensé est compensé par la comm totale rapporté par la population. merci à votre dispo pour préciser, thomas. |
[BIN-674] [Abonnement] : Abonnement newsletter Création: 17/mai/10 14:21 Mise à jour: 18/nov./10 18:29 Résolue: 20/mai/10 11:02 |
|
| Etat: | Résolu |
| Projet: | Business Intelligence |
| Composants: | CRM |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Amélioration | Priorité: | Majeur |
| Rapporteur: | Carole Visser | Attribution: | Julien Girardet |
| Résolution: | Invalid | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
FRA - France
|
| Description |
|
Bonjour, Nous aimerions suivre le nombre d'abonnés pour chacun de nos groupes d'abonnement. Il existe déjà des rapports "Subscription" mais ils ne prennent pas en compte la notion de NPAI. Un projet a été mis en place dans le but de les flagger. Quand serait-il possible de prévoir l'exclusion des NPAI de ces rapports afin que l'on puisse les exploiter? Merci d'avance, Carole |
| Commentaires |
| Commentaire de Agathe Remy [ 20/mai/10 11:02 ] |
|
Bonjour Carole, Le projet TX actuellement en Production identifie les NPAI des mails applicatifs. Ceux-ci n'ont rien à voir avec les NPAI 1M et les groupes d'abonnement. A ta dispo, Agathe |
| Commentaire de Agathe Remy [ 07/juin/10 14:23 ] |
|
Bonjour Carole, Pour info, au 06/06/2010, nous comptabilisons seulement 14 440 comptes dont l'email a été invalidé par PM. Cela ne me paraît donc pas urgent d'intégrer ces NPAI dans les rapports BI. Stp, peux-tu me le valider ? Merci, Agathe |
[APP-31784] Annulation d'une vente : pas de mail au vendeur Création: 15/nov./10 17:33 Mise à jour: 26/nov./10 10:35 |
|
| Etat: | Ré-ouvert |
| Projet: | Application PriceMinister |
| Composants: | Mails |
| Affecte la/les version(s): | 81.1.0 (MEV diverses) |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Majeur |
| Rapporteur: | Christophe Garcia | Attribution: | Habib-Sylvain Gourguet |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pays: |
ALL - Tous
|
| Site: | Integ |
| Projets PM: | CoSAV : Gestionnaire de commande |
| Description |
|
Quand le vendeur annule, on dit à l'acheteur qu'on a envoyé un message pour gronder le vendeur : même pas vrai !
Aucun message reçu côté vendeur. |
| Commentaires |
| Commentaire de Thomas Landru [ 15/nov./10 18:25 ] |
|
Testé sur le tronc, tout est ok :
voir les fiches articles suivantes annulation post claim : http://bo.dev11.pm.dev/purchase_back?action=itemview&itemid=105024540 annulation post vente : http://bo.dev11.pm.dev/purchase_back?action=itemview&itemid=105024543 |
| Commentaire de Christophe Garcia [ 16/nov./10 11:02 ] |
| Ce n'est pas ce que l'on peut appeler "un avertissement au vendeur pour qu'il s'assure de la disponibilité de ses produits" (voir message affiché côté acheteur). |
| Commentaire de Thomas Landru [ 17/nov./10 10:06 ] |
| Habib il faudrait revoir le contenu du mail suite aux remarques de Christophe. |
| Commentaire de Habib-Sylvain Gourguet [ 17/nov./10 10:28 ] |
|
Le rappel en question est fait au vendeur lorsqu'une
réclamation pour "Non reçu" a été ouverte et que le vendeur a annulé en
FO (je vous laisse le soin de tester, bien que DEV11 soit apparemment
mort).
Dans le cas d'une annulation pré-claim du vendeur, il peut s'agir d'une rétractation de l'acheteur (que le vendeur soit pro ou part...). On considère que les vendeurs abusant de la fonctionnalité seront identifiés rapidement via rapports BI. En partant de ce principe, on peut dire que c'est le mail côté acheteur qui serait incohérent avec les règles citées ci-dessus... |
| Commentaire de Habib-Sylvain Gourguet [ 17/nov./10 10:29 ] |
|
Je décale (qu'on se mette d'accord ou non... :-).
Pas de traducteurs dispos avant le bouclage de la v81. |
[APP-30881] UK - Linkshare - Implémentation des tags Création: 01/sept./10 14:59 Mise à jour: 01/déc./10 17:21 Résolue: 01/déc./10 12:44 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Affiliation |
| Affecte la/les version(s): | 76.0.1.1 |
| Version(s) corrigée(s): | 82.0.1.1 |
| Type: | Tâche | Priorité: | Majeur |
| Rapporteur: | Benjamin Guerville | Attribution: | Rémi Virlouvet |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
BUY avec 3 items.jpg
BUY.jpg
FIRST ADVERT.jpg
FIRST BUY avec 3 items.jpg
FIRST BUY, with improved alignment.jpg
FIRST BUY.jpg
Pixel Integration LinkShare 2010.pdf
Webservices_LinkShare_QuickStart.pdf
|
| Pays: |
GBR - Royaume Uni
|
| Site: | Prod |
| Projets PM: | *** A PLANIFIER *** |
| Classif FONC: | comarket |
| Description |
|
Bonjour,
Nous allons travailler avec la plateforme d'affiliation Linkshare au UK (c'est une société du groupe Rakuten). 1/ Il faut supprimer les tags tradedoubler (ceux mis en place via le JIRA 2/ Il faut implémenter les tags Linkshare (voir doc en pj). C'est Thomas Springett qui va gérer le projet de notre côté. Merci BG |
| Commentaires |
| Commentaire de Thomas Springett [ 14/sept./10 16:44 ] |
|
Nous avons besoin de 2 tags:
ACHAT: avec les paramètre: mid= code priceminister ord=numero panier Skulist=product ID et dans le cas d'un "Firstbuy" FIRST_BUY. qlist=Quantité des article commandé (et dans le cas d'un first buy il faut aissi inclure 1 pour le firstbuy) amtlist=PriceMinister commission cur=GBP Namelist=valear du panier MISE EN VENTE mid= code priceminister ord=Seller ID Skulist=NEW SELLER. qlist=1 amtlist=0 cur=GBP Namelist=Vide |
| Commentaire de Ariane Baldinger [ 15/sept./10 09:12 ] |
|
OK.
Thomas, est-ce que Linkshare t'as indiqué les 'mid' à mettre ? Merci de nous les communiquer. |
| Commentaire de Thomas Springett [ 15/sept./10 09:41 ] |
|
Pas de Mid encore.
Je vais le demander. |
| Commentaire de Ariane Baldinger [ 30/sept./10 10:56 ] |
| NB : pour le tag ACHAT, dans le paramètre amtlist la commission doit être multipliée par 100. |
| Commentaire de Thomas Springett [ 30/sept./10 11:03 ] |
| Serait il possible de tester les tags avec le MID temperaire? |
| Commentaire de Ariane Baldinger [ 30/sept./10 11:11 ] |
|
Salut Thomas,
On reprend le même code de traking que celui paramétré pour Tradedoubler ? (i.e.1408140) |
| Commentaire de Thomas Springett [ 30/sept./10 11:15 ] |
|
Bon question.
Il faut voir si on peut modifier le nom en BO et sur Xiti. J'aurait le reponse cette aprem. Thanks, |
| Commentaire de Ariane Baldinger [ 30/sept./10 11:48 ] |
|
Quelques précisions :
Tag VENTE: on tracke FIRST_ADVERT, on n'utilise pas le paramètre 'namelist", la quantité est fixe "1", ainsi que le 'skulist' = "NEWSELLER" Tag ACHAT : il s'agit de la quantité d'articles qu'il faut mettre dans le 'qlist'. Thomas, peux-tu nous fournir les mid temporaires en attendant les définitifs ? Merci On vise une mise en Prod le 12/10. |
| Commentaire de Thomas Springett [ 30/sept./10 12:08 ] |
|
Ok pour garder les codes traking creer pour tradedoubler UK, 1408140 toujours.
Merci, |
| Commentaire de Thomas Springett [ 30/sept./10 16:07 ] |
|
Info sur les tracking.
I would like to give further follow up in regards to technical integration. You have two options Private domain w/ 301 redirect . Affiliate links will use the domain linksynergy.priceminister.com. PriceMinister will setup a CNAME on PriceMinister DNS that maps the domain to our click server. Affiliate links will still technically pass through our system via the CNAME reference. Tracking works as normal. Private domain w/ direct link . Affiliate links will use the domain linksynergy.priceminister.com. PriceMinister will need to setup gateway pages for every variation of click through url we publish (see list below). This is more involved for the PriceMinister as you need setup a process that will handled traffic into the multiple urls, call the LS click server to produce a tracking code and finally redirect the user to the destination. http://linksynergy.priceminister.com/fs-bin/click?id=xxxx&offerid=xxxx.xxxxx&type=xxxx&subid=0&u1=xxxx http://linksynergy.priceminister.com/deeplink?id=xxxx&mid=xxxx&murl=xxxx http://linksynergy.priceminister.com/fs-bin/stat?id=xxxx&offerid=xxxx.xxxxx&type=xxxx&subid=0&u1=xxxx http://linksynergy.priceminister.com/fs-bin/statform? http://storefront.linksynergy.priceminister.com/fs-bin/store |
| Commentaire de Thomas Springett [ 11/oct./10 11:47 ] |
|
Bonjour,
Nous avons un changement de méthode de rémunération affiliée pour linkshare. Jusque 01/02/2011 nous alon payer un % du order value. Il faut donc changer les attributs: Maintenons: amtlist=valeur du panier cur=GBP Namelist=PriceMinister commission et nous remettons amtlist=PriceMinister commission cur=GBP Namelist=valear du panier pour fevrier. j'attends toujours le MID de la part de Linkshare. Merci, |
| Commentaire de Ariane Baldinger [ 14/oct./10 18:50 ] |
| en standby : TLE doit s'accorder avec Linkshare sur la techno à mettre en place |
| Commentaire de Thomas Springett [ 29/oct./10 11:25 ] |
|
Petit changement de format des tags et de wording pour le Firstbuy...
Here it is what it’s need to be done technically - PM needs to be able to determine if order is completed by new or existing customer. - If new customer, you will include an extra item denoting this. The item will be defined as skulist=newcustomer, qlist=1, amtlist=0, namelist=New%20Customer. All other elements in the pixel will be configured as per spec. For example, if a new customer purchases SKU1, SKU2 and SKU3, the pixel will look like this: <img height="1px" width="1px" border="0" alt="" src="https://track.linksynergy.com/ep?mid=36489&cur=GBP&tr=lMh2Xiq9xN0-1qmuLgdHkn_tqpk_qqYBtg&land=20101019_2245ord=12345&skulist=SKU1|SKU2|SKU3|newcustomer&qlist=1|2|1|1&amtlist=2400|5000|1000|0&namelist=Product%20Name%201|Product%20Name%201|Product%20Name%202|Product%20Name%203|New%20Customer"> - If existing customer, you will append a “-E” to the end of every SKU value. All other values in the pixel will be the same. For example, if an existing customer purchases SKU1, SKU2 and SKU3, the skulist will look like: skulist=SKU1-E|SKU2-E|SKU3-E. <img height="1px" width="1px" border="0" alt="" src="https://track.linksynergy.com/ep?mid=36489&cur=GBP&tr=lMh2Xiq9xN0-1qmuLgdHkn_tqpk_qqYBtg&land=20101019_2245ord=12345&skulist=SKU1-E|SKU2-E|SKU3-E&qlist=1|2|1&amtlist=2400|5000|1000&namelist=Product%20Name%201|Product%20Name%201|Product%20Name%202|Product%20Name%203"> |
| Commentaire de Thierry Leforestier [ 10/nov./10 12:09 ] |
|
Bonjour,
Nous avons enfin réussi a faire fonctionner la solution SEO friendly avec LinkShare et pouvons implémenter le pixel tracker comme fourni par LinkShare. La seule différence pour que tout fonctionne, c'est qu'il faut systématiquement remplacer track.linksynergy.com par trackls.priceminister.co.uk. Sinon tout est pareil. Si vous avez des questions etc, n'hésitez pas. Concernant les tests, nous pouvons éventuellement simuler les cookies posés par LinkShare pour vérifier que tout fonctionne en environnement de dev. Je veux bien être inclu dans ce process afin de m'assurer que tout se passe correctement. |
| Commentaire de Thierry Leforestier [ 22/nov./10 14:50 ] |
|
Donc, comme l'utilisation d'un sous domaine posait des
problèmes avec le protocole sécurisé, nous avons utilisé la même méthode
que pour l'arrivée de l'internaute, a savoir le ProxyPass.
Il faut donc finalement utiliser à la place de track.linksynergy.com/ep... l'url suivante : https://www.priceminister.co.uk/trackls/ep Merci !! Thierry |
| Commentaire de Thomas Springett [ 22/nov./10 17:16 ] |
| MID:36489 |
| Commentaire de Rémi Virlouvet [ 22/nov./10 18:23 ] |
|
je résume et j'actualise :
ACHAT: avec les paramètres: mid=36489 ord=numero panier Skulist=product IDs qlist=Quantité des articles commandés sera toujours 1 (vu avec Damien, on ne peut faire autrement) amtlist=valeur du panier, par articles cur=GBP |
| Commentaire de Rémi Virlouvet [ 24/nov./10 11:34 ] |
| Thomas, can you please let me know about the new parameters for mise en vente ASAP? I'm setting up the tags right now, and it would be lovely if we could test them together today. |
| Commentaire de Thomas Springett [ 24/nov./10 11:53 ] |
|
mid= 36489this is correct
ord=Seller IDThis should be orderID of the sales, please let me know if I understood correctly. Skulist=NEW SELLER. this is correct , recommended name is newcustomer or set yours as newseller without the space. qlist=1 this is correct amtlist=0 this is correct cur=GBP this is correct Namelist=Emptyyou can leave this empty, recommended name is New%20Customer |
| Commentaire de Rémi Virlouvet [ 25/nov./10 11:00 ] |
| en attente d'un support dev pour la somme à multiplier par 100 |
| Commentaire de Rémi Virlouvet [ 29/nov./10 18:45 ] |
| débloqué par Arnaud. je reprends le param. |
| Commentaire de Rémi Virlouvet [ 29/nov./10 19:10 ] |
|
<img src="$!{urlBlocker}https://www.priceminister.co.uk/trackls/ep?mid=36489&ord=$purchase.purchaseId&skulist=#set( $existingcu = "-E" )
#set($vCount = 0) #foreach( $item in $purchase.ItemFormatCollection ) #if($vCount > 0)| #end $item.productId$existingcu #set($vCount = $vCount + 1) #end&qlist= #set($vCount = 0) #foreach( $item in $purchase.ItemFormatCollection ) #if($vCount > 0)| #end 1 #set($vCount = $vCount + 1) #end&amtlist= #set($vCount = 0) #foreach( $item in $purchase.ItemFormatCollection ) #if($vCount > 0)| #end $format.numberRelevant($item.itemSalePrice.multiply(100).convertIntoDefaultCurrency().doubleObjectValue()) #set($vCount = $vCount + 1) #end &cur=GBP"> |
| Commentaire de Thomas Springett [ 30/nov./10 16:08 ] |
|
1408140
tracking code for BI |
| Commentaire de Rémi Virlouvet [ 30/nov./10 16:27 ] |
|
code mis.
tradedoubler désactivé. |
| Commentaire de Rémi Virlouvet [ 30/nov./10 17:55 ] |
| tags testés côté param, avec un ou plusieurs articles (pour buy et first buy). tout est ok, jolie URL sur une ligne avec tout ce qu'il faut :) |
| Commentaire de Rémi Virlouvet [ 30/nov./10 18:00 ] |
|
cms ref
promotions /promotions/Promotions/GB/Affiliation/LinkShare/MEV - English (UK) (353816) /promotions/Promotions/GB/Affiliation/LinkShare/FIRST BUY - English (UK) (353883) /promotions/Promotions/GB/Affiliation/LinkShare/BUY - English (UK) (353815) /promotions/Promotions/GB/Affiliation/LinkShare - English (UK) (353814) |
[APP-27364] Possibilité de gérer à partir de l'application les inventaires Création: 23/nov./09 15:55 Mise à jour: 05/janv./11 12:06 Résolue: 05/janv./11 12:06 |
|
| Etat: | Résolu |
| Projet: | Application PriceMinister |
| Composants: | Produits |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 88.0.0 (VEN-G) |
| Type: | Nouvelle fonctionnalité | Priorité: | Majeur |
| Rapporteur: | Frédéric Nahum | Attribution: | Dispatcher (Pôle VEN) |
| Résolution: | Aucune correction envisagée | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
20091123_stock_taa_too.csv
|
| Pays: |
FRA - France
|
| Site: | Prod |
| Projets PM: | *** STANDBY *** |
| Classif1: | IMPORT |
| Classif2: | export inventaire |
| Description |
|
Nous avons de plus en pus de problème a maintenir les
inventaires et les fichiers d'erreur des partenaires passant par FTP,
car tous les scripts fait par Eric deviennent obselete avec toutes les
modifications de l'application. Il faudrait pouvoir gérer : 1/ Génération automatique de l'inventaire (chaque jour, lundi ,mar , etc...) sur le FTP du pro 2/ fichier d'erreur (comme accessible, vi BO) à partir du FTP (cf. |
| Commentaires |
| Commentaire de Frédéric Nahum [ 23/nov./09 15:55 ] |
| exemple d'inventaire en pièce jointe |
| Commentaire de Gaël Seguillon [ 01/déc./09 10:08 ] |
| Nous avons de plus en plus de demandes en ce sens et de moins en moins de capacité à gérer ces flux de façon stable et durable car chaque modification de l'appli demandent ensuite de retravailler les scripts , cela plaide fortement pour la mise en place de webservices permettant aux comptes concernés de venir chercher sans notre intervention manuelle ce type de données. |
| Commentaire de Edouard Gomez-Vaez [ 07/déc./09 17:32 ] |
|
Bien reçu :-). Nous avons déjà commencer à y réfléchir sérieusement. Pour l'export inventaire : une solution BI pourrait être moins coûteuse (en charge et en dev) et correspondrait peut-être plus au besoin. Pour l'export Erreur, et inventaire si l'on ne peut pas passer par le BI, il faut que nous aillons voir Eric, ce que nous ferons dès que la V59 est sortie. |
| Commentaire de Edouard Gomez-Vaez [ 14/déc./09 17:24 ] |
|
Expression des besoins en cours : http://pricewiki.lan/Wiki.jsp?page=Conception%20export%20inventaire%20et%20erreurs |
| Commentaire de Frédéric Nahum [ 16/déc./09 09:56 ] |
|
En ce qui concerne les inventaires, il faut qu'il arrive
dans leur FTP donc sur bacchus, le problème est que pour certains pros
l'inventaire contient plus de 1 million de lignes donc très long. Et c'est actuelement le problème le cumul des 'inventaire de plusieurs pro à la suite prenne beacoup de temps et donc en une journée tous les pros n'ont pas temps de passer. |
| Commentaire de Edouard Gomez-Vaez [ 02/mars/10 11:24 ] |
| Pour l'instant, c'est plus le problème de copie de fichier qui bloque. |
| Commentaire de Manuel Sadok [ 05/janv./11 12:06 ] |
| Ces problématiques sont prises en compte dans le cadre des WS déjà livrés depuis et dans leurs futures évolutions. |
[APP-25936] Xiti : visites provenant de campagnes emailing alors qu'aucune campagne emailing n'est en cours Création: 16/juil./09 09:33 Mise à jour: 17/janv./11 19:08 |
|
| Etat: | Ouvert |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | Aucune |
| Type: | Bogue | Priorité: | Mineur |
| Rapporteur: | Charles Decaux | Attribution: | Dispatcher (Pôle CTN) |
| Résolution: | Non résolu | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
screenshot-1.jpg
screenshot-2.jpg
|
| Pays: |
GBR - Royaume Uni
|
| Projets PM: | *** CHASSE *** |
| Classif1: | XITI |
| Classif FONC: | webanalytics |
| Description |
|
Hello, j'ai des visites provenant de "campagnes emailing" selon Xiti, alors que je ne fais aucune campagne emailing en ce moment. Par ailleurs, les seules campagnes correspondant à "campagnes emailing" sont "Priceletter-uk" et "Parrainage". Or, nous ne faisons pas de priceletter et le parrainage est encore trop confidentiel pour générer autant de visites. J'attache 2 screenshots : - l'un avec tous les groupes de tracking montrant qu'au UK, seuls Priceletter uk et parrainage sont les seuls groupes de trackings en "EPR" - l'autre montrant les visites xiti issues de campagnes emailling Serait-il possible de creuser pour comprendre pourquoi on a autant de visites provenant de campagnes emailing ? Merci |
| Commentaires |
| Commentaire de Alexandre Garnier [ 16/juil./09 10:20 ] |
|
Pourquoi ya "Parrainage" et "Parrainage_UK" ? Parrainage contient juste le tracking FILLEUL 20 (classique) qui est utilisé dans les mails de parrainage. Tandis que Parrainage_UK en contient d'autres et le FILLEUL avec 135414 qui n'est pas utilisé dans les mails... Au passage aussi, on a le tracking 1352140 (Parrain_WidgetUK) qui est utilisé dans le mail "contact parrainage via widget (texte)" mais c'est le tracking 1352141 (Filleul_WidgetUK). De plus, les mails de relance utilise le tracking 20 de parrainage classique. En gros c'est un peu le bordel dans l'utilisation des tracking de parrainage et les templates de mail qui les utilisent. Alors d'ici à ce qu'il y ai eu une autre erreur dans l'utilisation d'un tracking parrainage à la place d'un autre ... Sinon, pas vraiment évident de voir d'où ça peut venir. Il faudrait voir avec les rapports BI si les mails de parrainages n'ont pas été beaucoup plus envoyés, ou voir à quels utilisateurs sont assignés ses tracking et si cela correspond bien à des parrainages ou non. Voir aussi si dans l'hitorique des mails UK envoyés via les newsletters ou autre, on a pas utilisé ces trackings par erreur. |
| Commentaire de Charles Decaux [ 16/juil./09 14:33 ] |
|
Il y a "parrainage" et "parrainage_UK" car j'avais commencé à
créer le groupe de trackings jusqu'à ce qu'on me dise que cela relève
du dev, qui a alors crée un nouveau groupe de tracking Ensuite, je pense qu'il y a eu une confusion au niveau des trackings à utiliser pour le parrainage. Lors de la période de recette, je n'ai jamais pu correctement tester, car je ne recevais aucun mail depuis le serveur de dev ou d'integ Serait-il possible de m'envoyer tous les mailings liés au parrainage au format brut afin que je vérifie que ceux-ci utilisent les trackings corrects ? Attention, les confusions de trackings parrainage ne sont de toutes façons pas le problème soulevé par ce JIRA. En effet, quand je regarde les stats sous XiTi voici ce que j'obtiens sur la période du 15 juin au 15 juillet : En effet, sur la période du 15 juin au 15 juillet, voici les stats que j'ai : -Visites du groupe de tracking "parrainage" : 62 -Visites du groupe de tracking "parrainage_UK" : 3 -Visites du groupe de tracking "priceletter-UK" : 31 --> Total visites de ces 3 groupes qui sont les seuls à appartenir à EPR : 96 -Visites des campagnes emailing dans Xiti : 9821 Soit une erreur de 9725 visites, ce qui est monstrueux et pas logique. Il faudrait creuser le sujet, car cet écart s'agrandit de jour en jour. Merci |
| Commentaire de Charles Decaux [ 23/juil./09 11:00 ] |
|
Hello, Les visites campagnes emailing ne cessent de croître sans explication rationnelle. Je retranscris ici une discussion avec XiTi qui aurait tendance a privilégier la piste d'un problème de catégorisation des xtor chez nous. A votre dispo pour en parler 1.Votre question - 23/07/2009 09:48 Bonjour, dans la vue Sources > sources > sources, je souhaiterais savoir d'où proviennent ces statistiques. Sont-elles récupérées grâce à l'utilisation d'un xtor ? Ou bien sont elles identifiées grâce au referer ? Merci de votre retour 2.Réponse apportée - 23/07/2009 09:55 Bonjour, Les campagnes promotionnelles que vous avez déclarées sont identifiées grâce au XTOR : - Affiliation et partenaires - Campagnes d'emailing - Liens Sponsorisés ... Tous les autres accès sont classés en fonction du referer : - Moteurs (i.e. ref=google.com) - Accès Direct (pas de referer ou poursuite de visite) - Sites affluents (ref=domaine.com) - Emails (i.e. ref=gmail.com, seulement les webmails sont identifiés) ... Cordialement, Remi Boudard http://www.atinternet.com 3.Votre question - 23/07/2009 10:11 Merci pour votre réponse. Que se passe-t-il si une visite provient de gmail avec un xtor qui est lié au type "affiliation et partenaires" ? Est-elle alors classée dans campagnes d'emailing, affiliation/partenaires ou bien dans emails ? Merci 4.Réponse apportée - 23/07/2009 10:28 Bonjour, Si votre xtor est correctement renseigné en tant que "affiliation et partenaires", alors cette visite sera classée dans affiliation et partenariats. Si une visite est issue d'un webmail et qu'elle n'a pas de xtor, alors elle est classée dans emails. N'hésitez pas à revenir vers nous si vous avez la moindre question. Cordialement, Florian Tamarelle http://www.atinternet.com |
| Commentaire de Alexandre Garnier [ 29/juil./09 18:41 ] |
|
La dernière phrase est intéressante : tout clic depuis un
webmail est attribué aux mails si on ne met pas de xtor (donc de
tracking) Donc s'il existe des liens dans des mails sans tracking ou que les gens se mettent à linker PM dans leurs mails, ça pourrait expliquer. |
| Commentaire de Charles Decaux [ 12/août/09 14:42 ] |
|
Vu avec Swan : en fait, le groupe de tracking "Shopping.com"
avait été à l'origine crée en tant que campagne email marketing. Je l'ai modifié par la suite, pour le mettre dans affiliation et partenaires, mais cette modification n'a pas été prise en compte par Xiti. Je vais faire un msg à Xiti et je vous tient au courant |
[APP-31530] Répartition Tracking Création: 27/oct./10 11:09 Mise à jour: 11/févr./11 14:42 Résolue: 02/févr./11 14:52 |
|
| Etat: | Fermé |
| Projet: | Application PriceMinister |
| Composants: | Aucune |
| Affecte la/les version(s): | Aucune |
| Version(s) corrigée(s): | 87.0.0 (CTN-W) |
| Type: | Nouvelle fonctionnalité | Priorité: | Critique |
| Rapporteur: | Carole Visser | Attribution: | Emmanuel Letailleur |
| Résolution: | Corrigé | ||
| Estimation restante: | Non spécifié | ||
| Temps consacré: | Non spécifié | ||
| Estimation originale: | Non spécifié | ||
| Pièces jointes: |
Liste des tracking a migrer.xlsx
|
| Pays: |
FRA - France
|
| Projets PM: | *** CHASSE *** |
| WishList: | Marketing |
| Classif1: | XITI |
| Classif FONC: | webanalytics |
| Description |
|
Bonjour,
Il y a toujours des problèmes dans l'organisation des groupes de tracking. Pour simplifier la collecte des résultats, j'ai créé un nouveau groupe de tracking "News-Fonctionnalités" dans xiti et dans le BO. Vous trouverez en pièce jointe la liste des codes présents dans d'autres groupes de tracking et qu'il faudrait affecter dans le groupe News-Fonctionnalités. A votre dispo si vous avez des questions, Carole |
| Commentaires |
| Commentaire de Carole Visser [ 25/janv./11 14:51 ] |
|
Bonjour,
Avez vous pu avancer sur cette demande? Merci Carole |
| Commentaire de Carole Visser [ 25/janv./11 16:39 ] |
|
Bonjour,
Il faudrait également déplacer le tracking "Souhait" présent dans le groupe de tracking "Default" vers le groupe de tracking "Souhait". Cette modification est assez urgente car nous allons recommencer dès ce soir à réaliser des tests sur le mail applicatif souhait. Il faudrait donc que l'ensemble du VA généré par cet email se trouve dans le même groupe de tracking. Merci Carole |
| Commentaire de Fabrice Feugas [ 26/janv./11 15:52 ] |
| On va le regarder ASAP. |
| Commentaire de Renaud Dierickx [ 31/janv./11 17:15 ] |
|
OK, êtes-vous bien sûr de vouloir faire ça ?
Il y aura sans doute des répercussions sur vos rapport BI ? On traite ça pour la CTN-W. |
| Commentaire de Julien Meraud [ 31/janv./11 18:14 ] |
|
Oui, on est vraiment sûrs. En fait, il y a des groupes de
tracking trop hétérogènes dans lesquels il y a des souhaits, des news
etc... ce qui nous contraint à sortir les chiffres tracking par tracking
alors que lorsque cela sera corrigé, on pourra sortir les chiffres
groupes de tracking par groupes de tracking ce qui simplifiera
considérablement les reporting et allégera les fichiers excel.
Par contre, tu me confirmes que comme la dernière fois, l'historique sera lui aussi rebasculé dans les nouveaux groupes de tracking ? |
| Commentaire de Julien Girardet [ 31/janv./11 18:38 ] |
|
Si la modif consiste à changer l'association
tracking/tracking group, alors en effet le VA associé aux trackings
concernés sera lié au nouveau groupe de tracking (historique compris).
Julien. |
| Commentaire de Renaud Dierickx [ 02/févr./11 12:11 ] |
| On est d'accord que ça ne concerne que la france ! |
| Commentaire de Emmanuel Letailleur [ 02/févr./11 14:52 ] |
|
C'est fait en dev !
[CAJ2011Q1CTN] |
| Commentaire de Swan Desportes [ 03/févr./11 11:42 ] |
|
Pour les souhaits, on traite le sujet comme suit, de façon transverse aux trois plateformes (FR, ES, UK):
- creation d'un groupe "Souhait" (au singulier), id=30 - deplacement du tracking 30 "Souhait" dans ce nouveau groupe - déplacement des trackings FR du groupe 219280 (Souhaits) vers le nouveau groupe 30 (Souhait) - déplacement des trackings FR du groupe 239380 (Souhait) vers le nouveau groupe 30 (Souhait) Il n'y a pas de groupe "Souhait" ou "Souhaits" en ES et UK En attendant, la mise en prod, il est toujours possible de créer des trackings dans le groupe 239380 (Souhait) Merci |
| Commentaire de Emmanuel Letailleur [ 04/févr./11 12:02 ] |
|
C'est fait mais le nouveau groupe "Souhait" a finalement l'id 1030 et non pas 30.
Je récapitule ce qui a été fait : - les trackings FR listés dans le fichier excel ont été déplacés vers le groupe "News-Fonctionnalités" (id=235280) - creation d'un groupe "Souhait" (au singulier), id=1030 - deplacement du tracking 30 "Souhait" dans ce nouveau groupe - déplacement des trackings FR du groupe 219280 (Souhaits) vers le nouveau groupe 1030 (Souhait) - déplacement des trackings FR du groupe 239380 (Souhait) vers le nouveau groupe 1030 (Souhait) |
[EXP-2764] 